By default in Puppy the firewall logging is not enabled
To enable it AFTER using the firewall wizard go to

Here is a useful addition:
http://www.murga-linux.com/puppy/viewtopic.php?t=13731&sid=b5d3b97d57e6f2ced6dfa2e4d5259f47∞

OR

Humm...if you like a neat way to conviently view the logs in real time there is universal way to do it.

In RXVT type
tail -f /var/log/messages

please note there is a space between tail(space)-f(space)/var/log/messages

press enter

This will show every new entry to the firewall log
provided that this is where the FW sends its logs to as it does in Puppy (versions 2.10 and 2.12 for sure).

Now it will only scrolls back so far and will always jump to the bottom of the screen as the most recent log entry > autoscroll.

The data limit retained in standard mode is not very much I think so it sort of flushes out it self. Now depending on your surfing and what you have choosen to log this data could be moving rather fast.

But if you use a text editor and manually open the "messages" file the complete history of the firewall logs will still be there.

The advantange of using the method in the RXVT window is that it is a live and constantly updating of what you choose to log via the firewall or any other log or file for that matter, provided that you correctly point to it.

This command ought to work for many different things and reasons. The FW logs is a good one.

I didnt want to have any of the logs flushed until I reviewed them. But I have used this method described as above for real time monitoring of the firewall.

Also it is possible to determine what the firewall is doing:
In RXVT type
iptables -L -n -v --line-numbers

And it will show you, as an example "rule de jour" number 10 in my INPUT chain which will look like this:

10 33 49500 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW

There is a legend in a line right after the firewall category that has colums that will show you the defination of each colum.

In the above example:
-10 is the rule number in my INPUT chain (category)
-33 is the total number of packets dropped
-49500 bytes (total dropped from accessing my system)
-DROP is what the action of the rule is suppose to do
-tcp is the protocol of the rule
-the first * represents from anywhere to the IN
-the second * represent to anywhere on the OUT
-0.0.0.0/0 represents the generic source and output destination
-tcp flags:!0x17/0x02 state NEW >represents the firewall interpertation of what the rule actual is, althought this is not how the rule would actually be written.

As that rule would actually be written as:

iptables -A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP

Now if you were to use this rule to add to your firewall the -A in the rule means that it will append it to the INPUT chain, which means it will go to the bottom of the existing list. And I doubt that it would be effective there as a rule before it may actually accept it. So if you like to try this rule I would change the -A to -I. This change would insert the rule at the top of your existing INPUT chain rule set. Seems to be a good rule. The beauty of puppy is by using it as a LIVE CD where you can change anything and if it creates issues just reboot and you start fresh again.

Written as:

iptables -I INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP

Spaces and capitals are important as in Linux they mean 2 different things.

Also the thing about iptables is that what the order of the rules are is very important and makes a difference between what gets filtered and what doesnt. So that if a rule is not in the right order, you will either block your own access to the network or cause the rule to be ineffective. Although once you get the jest of it, it does make sense. And say you added a rule and it blocked your network access, just>
In RXVT type

iptables -L -n -v --line-numbers

and see, by the increase in bytes that is being DROPPED (most likely and INPUT rule) when you try and access the net, it is likely that is the rule that is causing the blocking of the access.

Here is a little tutorial on deciphering the meaning of firewall logs.
http://logi.cc/linux/netfilter-log-format.php3∞

The items are explained in sequence:
Apr 16 00:30:45
megahard kernel: syslog prefix. It is not present if you read log messages from the console.
NF: D(I,Priv)
Enabled with: --log-prefix 'prefix'
An arbitrary, user defined log prefix. Including the spaces.
A trailing space is necessary to keep the prefix separate from the next token; this is a bug in netfilter.

IN=eth1 Interface the packet was received from. Empty value for locally generated packets.

OUT= Interface the packet was sent to. Empty value for locally received packets.

MAC=
00:80:8c:1e:12:60:
00:10:76:00:2f:c2:
08:00 Destination MAC=00:80:8c:1e:12:60,
Source MAC=00:10:76:00:2f:c2,
Type=08:00 (ethernet frame carried an IPv4 datagram)

SRC=211.251.142.65 Source IP address

DST=203.164.4.223 Destination IP address

LEN=60 Total length of IP packet in bytes

TOS=0x00 Type Of Service, "Type" field.
Increasingly being replaced by DS and ECN. Refer to the IP header info below.

PREC=0x00 Type Of Service, "Precedence" field.
Increasingly being replaced by DS and ECN. Refer to the IP header info below.

TTL=44 remaining Time To Live is 44 hops.

ID=31526 Unique ID for this IP datagram, shared by all fragments if fragmented.

CE Presumably the "ECN CE" flag (Congestion Experienced).
This seems to be wrong because according to RFC2481, the CE bit is located in the TOS field. Refer to the IP header info below.

DF "Don't Fragment" flag.

MF "More Fragments following" flag.

FRAG=179 Fragment offset in units of "8-bytes". In this case the byte offset for data in this packet is 179*8=1432 bytes.

OPT (0727..A200) Enabled with: --log-ip-options
IP options. This variable length field is rarely used. Certain IP options, f.e. source routing, are often disallowed by netadmins. Even harmless options like "Record Route" may only be allowed if the transport protocol is ICMP, or not at all.

PROTO=TCP Protocol name or number. Netfilter uses names for TCP, UDP, ICMP, AH and ESP. Other protocols are identified by number. A list is in your /etc/protocols. A complete list is in the file protocol-numbers
SPT=4515 Source port (TCP and UDP). A list of port numbers is in your /etc/services. A complete list is in the file port-numbers

DPT=111 Destination port (TCP and UDP). See SPT above.

SEQ=1168094040 Enabled with: --log-tcp-sequence
Receive Sequence number. By cleverly chosing this number, a cryptographic "cookie" can be implemented while still satisfying TCP protocol requirements. These "SYN-cookies" defeat some types of SYN-flooding DoS attacks and should be enabled on all systems running public TCP servers.
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

ACK=0 Same as the Receive Sequence number, but for the other end of the TCP connection.

WINDOW=32120 The TCP Receive Window size. This may be scaled by bit-shifting left by a number of bits specified in the "Window Scale" TCP option. If the host supports ECN, then the TCP Receive Window size will also be controlled by that.

RES=0x03 Reserved bits. The ECN flags "CWR" and "ECNE" will show up in the two least significant bits of this field. Refer to the TCP header info below.
URG Urgent flag. See URGP below.
ACK Acknowledgment flag.
PSH Push flag.
RST RST (Reset) flag.
SYN SYN flag, only exchanged at TCP connection establishment.
FIN FIN flag, only exchanged at TCP disconnection.

URGP=0 The Urgent Pointer allows for urgent, "out of band" data transfer. Unfortunately not all protocol implementations agree, so this facility is hardly ever used.

OPT (020405...300) enabled with: --log-tcp-options

TCP options. This variable length field gets a lot of use. Important options include: Window Scaling, Selective
Acknowledgment and Explicit Congestion Notification. Refer to the TCP header info below.
Unfortunately the rule number in the chain which matched the packet is for architectural reasons not available in netfilter logs. You will have to "cook your own" by using the user-prefix feature.