I've been trying to understand a peculiar behavior in our routing/firewall setup for quite some time now, but don't really understand what's going on.

We have a firewall/router appliance that has two external facing interfaces and a number of internal VLANs.

The specific behavior is observed when a client (MAC f4:f5:d8:d2:f2:4c, IP 10.99.154.254 in this example) on our guest WiFi network VLAN 99 sends a ping echo request to some internet host 8.8.8.8, which we prohibit.

The router sends back an ICMP host unreachable packet from its vlan99 interface (MAC 00:08:a2:0d:00:70, IP 10.99.0.2) to the client, and at the exact same time we see a martian packet on the external interface eth-ext1:

tcpdump shows this:

$ tcpdump -i vlan99 -vvvvn 'icmp and host 10.99.154.254'
11:59:21.555564 f4:f5:d8:d2:f2:4c > 00:08:a2:0d:00:70, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.99.154.254 > 8.8.8.8: ICMP echo request, id 2303, seq 1, length 64
11:59:21.555651 00:08:a2:0d:00:70 > f4:f5:d8:d2:f2:4c, ethertype IPv4 (0x0800), length 126: (tos 0xc0, ttl 64, id 8585, offset 0, flags [none], proto ICMP (1), length 112)
    10.99.0.2 > 10.99.154.254: ICMP host 8.8.8.8 unreachable, length 92
    (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.99.154.254 > 8.8.8.8: ICMP echo request, id 2303, seq 1, length 64

Nothing surprising here, this is the original ping from the client and the resulting ICMP packet going back to the guest client informing them that the host is unreachable.

At the same time, an entry appears in the kernel log:

Feb 21 11:59:21 ganymede kernel: IPv4: martian source 10.99.154.254 from 8.8.8.8, on dev eth-ext1
Feb 21 11:59:21 ganymede kernel: ll header: 00000000: 00 08 a2 0d 00 70 f4 f5 d8 d2 f2 4c 08 00        .....p.....L..

The link layer information shows that this ethernet frame came from the client device to the router's vlan99 interface, which makes me wonder why it appears as a martian packet on eth-ext1 with a source address of 8.8.8.8.

I have failed so far to get a trace of the packet with the martian source, which leaves me wondering if martian source logging also happens on an egress interface, before tcpdump has a chance to see it?

I'll gladly provide more information on request (routing tables or the like), and would appreciate any pointers as to what's going on here.

  • I have no idea what is happening here, but at least I can tell you that 8.8.8.8 is one of Google's public DNS servers. A lot of people use them, and quite a few also use them as ping destinations to check connectivity. – Jenny D Jun 14 at 9:02
  • Might be helpful - unix.stackexchange.com/questions/166006/…. – slm Jun 15 at 0:06

The kernel is patching the ping request to 8.8.8.8 with the icmp unreachable message, and is helpfully telling you that the sourc is a martian.

This is the packet it is flagging...

11:59:21.555651 00:08:a2:0d:00:70 > f4:f5:d8:d2:f2:4c, ethertype IPv4 (0x0800), length 126: (tos 0xc0, ttl 64, id 8585, offset 0, flags [none], proto ICMP (1), length 112)
    10.99.0.2 > 10.99.154.254: ICMP host 8.8.8.8 unreachable, length 92

As you can see by the link layer... MAC 00 08 a2 0d 00 70 to f4 f5 d8 d2 f2 4c 08 00.

Feb 21 11:59:21 ganymede kernel: ll header: 00000000: 00 08 a2 0d 00 70 f4 f5 d8 d2 f2 4c 08 00 

Martian source - I assume it is conflating the fact that it is responding as a proxy to 8.8.8.8 - can't get there from here.

  • Thanks for the response. If I understand you right, the source IP in the martian log message is (wrongly) modified because the orginal packet would have been SNATed? And the listed interface is the external one for the same reason? – dorian Sep 21 at 9:12
  • Also, ethernet frames put the destination before the source, so the link layer part of the martian log message is actually the other way around. – dorian Sep 21 at 9:54

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.