1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Firewall log and ICMP dest - why local IP address?

Discussion in 'Tomato Firmware' started by dharr, Oct 19, 2012.

  1. dharr

    dharr Serious Server Member

    Why does the Tomato firewall log report my router's local address (192.168.xxx.xxx) as the destination for pings originating from the Internet, while it reports my cable modem's IP address (24.xxx.xxx.xxx) for TCP traffic coming from the Internet? I would have expected the ping destination to be the 24.xxx address, too, but instead, it's the 192.168.xxx.xxx local router address that I assigned myself.
     
  2. Nitro

    Nitro Networkin' Nut Member

    From a guess its because ICMP is not the same as TCP (different protocols). In TCP the destination is set before it leaves its source were as ICMP does not store destination addresses in its header, the reason you have the local ip in the log is most likely because the router running tomato was the one that responded to the ICMP Ping message and not the modem (reponding to ICMP is the routers job not the modems)
     
  3. dharr

    dharr Serious Server Member

    My understanding is that the ICMP packet header is an IP header that contains the destination address field, and in order to reach my computer from the Internet, it would contain my WAN IP address, the one assigned by my cable company. Is this incorrect?

    Here are a couple of abbreviated log entries, the first for a TCP packet:

    This is for an attempted connection to port 3389 from some unknown IP address on the Internet:

    Oct 16 00:24:44 unknown user.warn kernel: DROP IN=vlan2
    SRC=foreign IP address (presumed hacker)
    DST=WAN IP address (from cable modem, e.g. 24.xxx.xxx.xxx; this is expected)
    PROTO=TCP SPT=60648 DPT=3389

    This is for a ping from some IP address on the Internet, and it could be due to me initiating it at legit sites like network-tools.com and grc.com, plus from the presumed hackers:

    Oct 16 00:24:44 unknown user.warn kernel: DROP IN=vlan2
    SRC=foreign IP address (e.g. network-tools.com, grc.com, presumed hackers)
    DST=router's local IP address (192.68.xxx.xxx that I set; I expected it to be 24.xxx.xxx.xxx as above with TCP)
    PROTO=ICMP TYPE=8

    Nothing gets through; grc.com reports "True Stealth", and the Windows firewall doesn't log anything (and I verified its logger is in fact working). My guess is that the pings come in with DST equal to my WAN IP address; otherwise, how can they reach my computer? Then the firewall is for whatever reason substituting the router's local IP address when it logs it. I don't think there's a problem. I just want to understand this better.
     
  4. koitsu

    koitsu Network Guru Member

    This is completely and entirely wrong, on multiple levels. You need to become more familiar with the IP protocol before answering questions like this (I say that kindly/respectfully), as your current understanding is incorrect.
     
  5. koitsu

    koitsu Network Guru Member

    Please show the log messages and do not edit them. Please also disclose what exact firmware you're running (provide the firmware filename).
     
  6. koitsu

    koitsu Network Guru Member

    Thank you for the logs. I am in agreement -- I would expect the packet to have a destination IP of your WAN address. In fact, the packet should. If the ICMP type 8 (echo) packet was sent with a destination address in the IP header of 192.168.x.x across the Internet, it wouldn't ever reach your WAN -- Internet routers (and your ISP's gateway!) wouldn't know what to do with it (where to forward it).

    I'm not sure what's going on there. I don't have an explanation for why it shows your LAN address, especially since the log line shows IN=vlan2 (that's your WAN interface! There's no LAN IP bound to that!).

    I'm sure if you were to do tcpdump -p -i vlan2 -l -n -s 1024 "icmp" on the router and initiate one of those tests or an ICMP ping from the Internet to your WAN IP, you would see the destination address of your WAN IP. So this, to me, looks to be a logging bug of some kind. I'm not sure how the logging actually works in Linux (specifically these routers), so I'm not sure how to go about fixing it or what piece of code to look at.

    Could you also please disclose the exact firmware you're using (provide the filename please)? It may be a bug that has since been fixed but without knowing what firmware and version exactly I can't say.
     
  7. dharr

    dharr Serious Server Member

    The firmware I am running is the final tomato 1.28 from polarcloud on a WRT54GL. I have another WRT54GL running DD-WRT that does the same thing. Finally, I have a much more recent Linksys router running the latest tomato by Toastman, and it does the same thing. All three routers behave exactly the same. So, it's not a router-specific quirk, nor is it a Tomato-specific quirk. It seems to be an iptables logging phenomenon going back years in both Tomato and DD-WRT and still present today. (I tried tcpdump, but it's not compiled into the version of tomato I have installed.)

    So, at this point, I think it's just the way the firewall works. If anyone is up to turning on logging and enabling the reporting of dropped/blocked inbound packets, I'd be interested to learn how pings originating from the Internet are reported to you. You could go to http://network-tools.com and ping yourself or run a Shields-Up scan at https://www.grc.com/x/ne.dll?bh0bkyd2. Thanks.
     
  8. koitsu

    koitsu Network Guru Member

    I do not turn on firewall logging because all it would do is cater to my OCD. :) However, if you want verification of pings, not a problem:

    router:

    Code:
    root@gw:/tmp/home/root# tcpdump -p -i vlan2 -l -n -s 1024 "host 69.20.131.234 and icmp"
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on vlan2, link-type EN10MB (Ethernet), capture size 1024 bytes
    20:24:43.443395 IP 69.20.131.234 > 67.180.84.87: ICMP echo request, id 19410, seq 1, length 64
    20:24:43.443663 IP 67.180.84.87 > 69.20.131.234: ICMP echo reply, id 19410, seq 1, length 64
    20:24:44.445025 IP 69.20.131.234 > 67.180.84.87: ICMP echo request, id 19410, seq 2, length 64
    20:24:44.445217 IP 67.180.84.87 > 69.20.131.234: ICMP echo reply, id 19410, seq 2, length 64
    20:24:45.446391 IP 69.20.131.234 > 67.180.84.87: ICMP echo request, id 19410, seq 3, length 64
    20:24:45.446592 IP 67.180.84.87 > 69.20.131.234: ICMP echo reply, id 19410, seq 3, length 64
    20:24:46.447613 IP 69.20.131.234 > 67.180.84.87: ICMP echo request, id 19410, seq 4, length 64
    20:24:46.447815 IP 67.180.84.87 > 69.20.131.234: ICMP echo reply, id 19410, seq 4, length 64
    20:24:47.449265 IP 69.20.131.234 > 67.180.84.87: ICMP echo request, id 19410, seq 5, length 64
    20:24:47.449462 IP 67.180.84.87 > 69.20.131.234: ICMP echo reply, id 19410, seq 5, length 64
    20:24:48.450385 IP 69.20.131.234 > 67.180.84.87: ICMP echo request, id 19410, seq 6, length 64
    20:24:48.450591 IP 67.180.84.87 > 69.20.131.234: ICMP echo reply, id 19410, seq 6, length 64
     
    12 packets captured
    13 packets received by filter
    0 packets dropped by kernel
     
    root@gw:/tmp/home/root# ifconfig vlan2
    vlan2      Link encap:Ethernet  HWaddr E0:CB:4E:C0:00:C5
              inet addr:67.180.84.87  Bcast:67.180.87.255  Mask:255.255.252.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:52941139 errors:0 dropped:0 overruns:0 frame:0
              TX packets:22265463 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:622096968 (593.2 MiB)  TX bytes:2202611658 (2.0 GiB)
    
    Linux box:

    Code:
    koitsu@gen ~ $ ping 67.180.84.87
    PING 67.180.84.87 (67.180.84.87) 56(84) bytes of data.
    64 bytes from 67.180.84.87: icmp_req=1 ttl=53 time=49.4 ms
    64 bytes from 67.180.84.87: icmp_req=2 ttl=53 time=49.9 ms
    64 bytes from 67.180.84.87: icmp_req=3 ttl=53 time=50.2 ms
    64 bytes from 67.180.84.87: icmp_req=4 ttl=53 time=51.2 ms
    64 bytes from 67.180.84.87: icmp_req=5 ttl=53 time=49.4 ms
    64 bytes from 67.180.84.87: icmp_req=6 ttl=53 time=48.8 ms
    ^C
    --- 67.180.84.87 ping statistics ---
    6 packets transmitted, 6 received, 0% packet loss, time 5006ms
    rtt min/avg/max/mdev = 48.834/49.880/51.288/0.819 ms
     
    koitsu@gen ~ $ /sbin/ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 00:12:3f:20:41:8e
              inet addr:69.20.131.234  Bcast:69.20.131.255  Mask:255.255.255.0
              inet6 addr: fe80::212:3fff:fe20:418e/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:108806047 errors:0 dropped:23 overruns:0 frame:0
              TX packets:56067279 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:1733899163 (1.6 GiB)  TX bytes:2599753035 (2.4 GiB)
    
    As you can see:

    67.180.84.87 = my WAN IP address
    69.20.131.234 = a Linux shell machine I have access to

    I initiated pings from the Linux shell machine to my WAN IP address. My router is configured to permit ICMP for many reasons, which is why you see ICMP ECHO REPLY packets going from my WAN IP back to the Linux box.

    It still doesn't make any sense why the firewall logging piece shows the destination IP as the LAN IP. To me, that would indicate some kind of bug in iptables, but I can assure you it's purely a cosmetical one -- the above packet captures are proof.
     
  9. dharr

    dharr Serious Server Member

    You are wiser than me. :)

    I believe it. Still, it would be nice if someone running Tomato or even DD-WRT on a router could confirm the firewall logs the LAN IP (local router address, as I've been calling it) as the destination of the dropped pings instead of the WAN IP, which is what it should be logging, and what it does log for TCP packets.
     
  10. USNetboy

    USNetboy Networkin' Nut Member

    As koitsu has demonstrated, there is nothing wrong with the ICMP packets hitting the firewall. The reason for the "odd" destination address in the firewall log though is not a bug, but rather part of the tomato netfilter design. The firewall entry that is responsible for this is the 1st entry in the "nat" table, WANPREROUTING chain:

    Code:
    # iptables -t nat -L WANPREROUTING -vn
    Chain WANPREROUTING (1 references)
    pkts bytes target    prot opt in    out    source   destination       
    2601 79222 DNAT icmp -- *  *  0.0.0.0/0  0.0.0.0/0  to:192.168.5.1
    
    This is hardcoded in tomato and forces all ICMP traffic to go through the INPUT chain. This was done to make sure all ICMP traffic will be responded by the router, no matter what any routing decision will be done for this packet. To understand why this causes the log to exhibit this behavior one must understand the packet flow in netfilter. Though a full description of netfilter's packet flow is beyond the scope of this forum I'll share a brief description for this specific case. An ICMP packet hits the WAN interface, it will first enter the mangle table and traverse the PREROUTING chain (filled with QOS stuff in tomato). It will then enter the nat table and traverse the PREROUTING chain there. This is where it will hit the above rule and get translated. Now the packet has a different destination address (the router LAN address - in the case above 192.168.5.1). The packet will now enter the mangle table and traverse the INPUT chain (empty in tomato) and then will enter the filter table and traverse the INPUT chain. This specific chain contains the firewall logging rule (added if tomato is configured to log inbound traffic). This is why the log shows the destination address of ICMP packets as the internal address. They are translated before they are logged. Other packet types will not hit the above rule and will be logged (with their original source/destination) by the same logging rule in the INPUT chain of the filter table.
     
    roterado, dharr, ntest7 and 1 other person like this.
  11. dharr

    dharr Serious Server Member

    Ah, mystery solved. Thank you very much.
     

Share This Page