Linux IP Masquerade HOWTO
Prev | Chapter 7. Frequently Asked Questions | Next

# 7.20. ( Logs ) - Now that I have IP Masquerading up, I'm getting all sorts of weird notices and errors in the SYSLOG log files. How do I read the IPTABLES/IPCHAINS/IPFWADM firewall errors?

There is probably a few common things that you are going to see:

- MASQ: Failed TCP Checksum error: You might see this error when a packet coming from the Internet gets corrupt in the data section of the packet but the rest of it "seems" ok. When the Linux box receives this packet, it will calculate the CRC of the packet and determine that its corrupt. On most machines running OSes like Microsoft Windows, they just silently drop the packets but Linux IP MASQ reports it. If you get a LOT of them over your PPP link, first follow the FAQ entry above for "(Performance) - Masq seems is slow".

  If the (Performance) FAQ tips don't help and you run PPP over dialup or PPPoE, you might try adding the line "-vj" (disabled VanJacobson header compression) to your /etc/ppp/options file and restart the PPPd connection.

- Firewall hits: Because you are on the Internet with a decent firewall, you will be surprised with the number of users trying to penetrate your Linux box! So what do all these firewall logs mean?

  More so, if they are filling your logs, see the next FAQ entry on thoughts how to reduce all these log entries.

- The following details are from the TrinityOS - Section 10 documentation I also wrote:

          With the use of various firewall rulesets, a given ruleset can either
          DENY (silently drop) or REJECT traffic (sends back a ICMP error).  If
          firewall logging is enabled, the errors will show up in the SYSLOG
          "messages" file found at:

              Redhat: 	/var/log
              Slackware:	/var/adm

          If you take a look at one of these firewall logs, you would see something
          like:

          ---------------------------------------------------------------------
          IPTABLES:
          ---------
          Feb 23 07:37:01 Roadrunner kernel: IPTABLES IN=eth0 OUT=
            MAC=00:50:da:2e:e5:fb:00:03:47:73:c9:d2:08:00 SRC=12.75.147.174
            DST=100.200.0.212 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=39034 DF PROTO=TCP
            SPT=4313 DPT=23 WINDOW=32120 RES=0x00 SYN URGP=0

          IPCHAINS:
          ---------
          Feb 23 07:37:01 Roadrunner kernel: input REJECT eth0 PROTO=6
            12.75.147.174:1633 100.200.0.212:23 L=44 S=0x00 I=54054 F=0x0040 T=64

          IPFWADM:
          --------
          Feb 23 07:37:01 Roadrunner kernel: IP fw-in rej eth0 TCP 12.75.147.174:1633
            100.200.0.212:23 L=44 S=0x00 I=54054 F=0x0040 T=64

          ---------------------------------------------------------------------

      There is a LOT of information in just this one line of SYSLOG.  Lets break
      out this example.  You should refer back to the original firewall hit as you
      read this.

      --------------

          1. ===================================================================

      	- This packet firewall "hit" occurred on "Feb 23 07:37:01"

          2. ===================================================================

      	- This packet was logged on the "RoadRunner" computer via the kernel

          3. ===================================================================

      	- IPTABLES: the SYSLOG prepend string is "iptables" for information purposes

          - IPCHAINS: the packet was stopped on the INPUT chain

          - IPFWADM:  the packet was an IP packet

          4. ===================================================================

          - IPTABLES: the packet came IN on interface "eth0"

          - IPCHAINS: the packet was REJECTED (vs. dropped or accepted)

          - IPFWADM:  the packet was stopped on INPUT (vs. "fw-out" for OUT or
             "fw-fwd" for FORWARD)

          5. ===================================================================

          - IPTABLES: the packet had NO output interface

          - IPCHAINS: the packet came in on the "eth0" interface

          - IPFWADM:  the packet was REJECTED "rej" (vs. "deny" or "accept")

          6. ===================================================================

          - IPTABLES: this display's the MAC address of the source and destination
                      Ethetnet MAC address (only relivant for Ethernet networks)

          - IPCHAINS: the packet was IP protocol 6 or TCP
      		        * If you don't know that protocol 6 is for TCP, look at
                        your /etc/protocols file to see what other protocol numbers
                        are used for.

          - IPFWADM:  the packet on the "eth0" interface

          7. ===================================================================

          - IPTABLES: the packet's source IP address was 12.75.147.174

      	- IPCHAINS: the packet's source IP address was 12.75.147.174

          - IPFWADM:  the packet was a "TCP" packet

          8. ===================================================================

      	- IPTABLES: the packet's destination IP address was 100.200.0.212

          - IPCHAINS: the packet's source PORT was 1633

          - IPFWADM:  the packet's source IP address was 12.75.147.174

          9. ===================================================================

          - IPTABLES: the packet's length was 44 bytes

      	- IPCHAINS: the packet's destination IP address was 100.200.0.212

          - IPFWADM:  the packet's source PORT was 1633

          10. ===================================================================

          - IPTABLES: the packet's TOS markings (type of service which basically
                      means class of service) was 0x00 or zero.

          - IPCHAINS: the packet's destination PORT was 23 (telnet)
      		        * If you don't know that port 23 is for TELNETing, look at
                        your /etc/services file to see what other ports are used
                        for.

          - IPFWADM:  the packet's destination IP address was 100.200.0.212

          11. ===================================================================

          - IPTABLES: the packet's precedense markings (class of service) was
                      0x00 or zero.

          - IPCHAINS: the packet's length was 44 bytes

          - IPFWADM:  the packet's destination PORT was 23 (telnet)
      		        * If you don't know that port 23 is for TELNETing, look at
                        your /etc/services file to see what other ports are used
                        for.

          12. ==================================================================

          - IPTABLES: the packet's TTL or Time to Live was 64 or 64 router hops
      		        * Every router hop over the Internet will subtract (1) from
                        this number.  Usually, packets will start with a number of
                        255 (depends on the operating system) and if that number
                        ever reaches (0), it means that realistically, the packet
                        was lost in a network loop and should be deleted.

          - IPCHAINS: the packet's TOS markings (type of service which basically
                      means class of service) was 0x00 or zero.
      		        * divide this by 4 to get the Type of Service (presidence)

          - IPFWADM:  the packet was 44 bytes long

          13. ==================================================================

      	- IPTABLES: the packet had various TCP flags set such as SYN, SYN+ACK,
                      etc. (shown in HEX)

          - IPCHAINS: the packet had various TCP flags set (shown in hex)

          - IPFWADM:  the packet's TOS markings (type of service which basically
                      means class of service) was 0x00 or zero.

          14. ==================================================================

      	- IPTABLES: the packet's "don't fragment" or DF bit was set from the
                      source computer

          - IPCHAINS: the packet had a fragmentation offset of 40 (shown in HEX)

      		        --Don't worry if you don't understand this..
      		        * A value that started with "0x2..." or "0x3..." means the
                        "More Fragments" bit was set so more fragmented packets
                        will be coming in to complete this one BIG packet.
      		        * A value which started with "0x4..." or "0x5..." means that
                        the "Don't Fragment" bit was set
      		        * Any other values are the Fragment offset (divided by 8) to
                        be later used to recombine into the original LARGE packet

      	- IPFWADM:  the packet had various TCP flags set such as SYN, SYN+ACK,
                      etc. (shown in HEX)

          15. ==================================================================

      	- IPTABLES: the packet was a TCP packet

          - IPCHAINS: the packet's TTL or Time to Live was 64 or 64 router hops
      		        * Every router hop over the Internet will subtract (1) from
                        this number.  Usually, packets will start with a number of
                        255 (depends on the operating system) and if that number
                        ever reaches (0), it means that realistically, the packet
                        was lost in a network loop and should be deleted.

          - IPFWADM:  the packet had a fragmentation offset of 40 (shown in HEX)

      		        --Don't worry if you don't understand this..
      		        * A value that started with "0x2..." or "0x3..." means the
                        "More Fragments" bit was set so more fragmented packets
                        will be coming in to complete this one BIG packet.
      		        * A value which started with "0x4..." or "0x5..." means that
                        the "Don't Fragment" bit was set
      		        * Any other values are the Fragment offset (divided by 8) to
                        be later used to recombine into the original LARGE packet

          16. ==================================================================

          - IPTABLES: the packet's soure PORT was 4313

          - IPCHAINS:

          - IPFWADM:  the packet's TTL or Time to Live was 64 or 64 router hops
      		        * Every router hop over the Internet will subtract (1) from
                        this number.  Usually, packets will start with a number of
                        255 (depends on the operating system) and if that number
                        ever reaches (0), it means that realistically, the packet
                        was lost in a network loop and should be deleted.

          17. ==================================================================

          - IPTABLES: the packet's destination PORT was 23 (telnet)
      		        * If you don't know that port 23 is for TELNETing, look at
                        your /etc/services file to see what other ports are used
                        for.

          - IPCHAINS:

          - IPFWADM:

          18. ==================================================================

          - IPTABLES: the packet's TCP window (sliding or selective TCP ack)
                      was 32120 bytes

          - IPCHAINS:

          - IPFWADM:

          19. ==================================================================

          - IPTABLES: the packet's TCP reserved bits were 0x00 (HEX) - unused

          - IPCHAINS:

          - IPFWADM:

          20. ==================================================================

          - IPTABLES: the packet's TCP header SYN bit was set
                      * IPTABLES displays all the TCP header bits by name and not
                        by a HEX dump

          - IPCHAINS:

          - IPFWADM:

          21. ==================================================================

          - IPTABLES: the packet's TCP header URGENT bit was set - rarely used

          - IPCHAINS:

          - IPFWADM:

Prev | Home | Next
( PORTFW - Locally ) - I can't reach my PORTFWed server from the INTERNAL lan | Up | ( Log Reduction ) - My logs are filling up with packet hits due to the new "stronger" rulesets. How can I fix this?