How to disable the default drop of martian packets?

nikmit · 03-30-2012, 09:30 AM

I would like to be able to handle such packets in iptables and have some control.
/proc/sys/net/ipv4/conf/eth1/log_martians is already at 0, but they are still dropped and still logged.
Using Debian Squeeze.

unSpawn · 03-30-2012, 10:42 AM

Quote:

Originally Posted by nikmit

I would like to be able to handle such packets in iptables and have some control.

You can't because you don't have a route: nobody (except NASA) routes packets from Mars.

nikmit · 03-30-2012, 11:37 AM

I don't want to route them, I just want to see them come:

ping -I tun0 4.2.2.2
PING 4.2.2.2 (4.2.2.2) from 172.16.8.2 tun0: 56(84) bytes of data.
^C
--- 4.2.2.2 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

tcpdump -i tun0 -n icmp
17:27:15.816583 IP 172.16.8.2 > 4.2.2.2: ICMP echo request, id 10330, seq 1, length 64
17:27:15.846702 IP 4.2.2.2 > 172.16.8.2: ICMP echo reply, id 10330, seq 1, length 64
17:27:16.824973 IP 172.16.8.2 > 4.2.2.2: ICMP echo request, id 10330, seq 2, length 64
17:27:16.864563 IP 4.2.2.2 > 172.16.8.2: ICMP echo reply, id 10330, seq 2, length 64

less /var/log/kern.log
Mar 30 17:27:16 gate kernel: [203953.009717] martian source 172.16.8.2 from 4.2.2.2, on dev tun0
Mar 30 17:27:17 gate kernel: [203954.001753] martian source 172.16.8.2 from 4.2.2.2, on dev tun0

Thinking about it, this is probably a misconfiguration or a bug, as neither the source nor the destination is 'martian'.

WizadNoNext · 03-31-2012, 12:28 PM

Quote:

Originally Posted by nikmit

I would like to be able to handle such packets in iptables and have some control.
/proc/sys/net/ipv4/conf/eth1/log_martians is already at 0, but they are still dropped and still logged.
Using Debian Squeeze.

As you stated here you turned off martians on eth1. eth1 isn't tun0! You need to turn them for specific interface - in your case tun0

Code:

echo 0 >/proc/sys/net/ipv4/conf/tun0/log_martians

But this would only turn off loggin martians, not dropping them.

Quote:

log_martians - BOOLEAN
Log packets with impossible addresses to kernel log.
log_martians for the interface will be enabled if at least one of
conf/{all,interface}/log_martians is set to TRUE,
it will be disabled otherwise

Any way: what kind of netmask are you using, if 172.16.8.2 is martian? Martian is packet coming from impossible address (e.g. broadcast) and kernel isn't making errors on such simple task.

nikmit · 04-02-2012, 02:49 AM

Quote:

Originally Posted by WizadNoNext

Any way: what kind of netmask are you using, if 172.16.8.2 is martian? Martian is packet coming from impossible address (e.g. broadcast) and kernel isn't making errors on such simple task.

tun0 is a VPN tunnel. It grabs traffic at my local firewall and tunnels it to a remote server, where it is NATed and sent on.

Code:

root@box:~# ifconfig tun0                                                         
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:172.16.8.2  P-t-P:172.16.8.1  Mask:255.255.255.255             
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1               
          RX packets:106851 errors:0 dropped:0 overruns:0 frame:0                  
          TX packets:107911 errors:0 dropped:0 overruns:0 carrier:0                
          collisions:0 txqueuelen:100                                              
          RX bytes:8975484 (8.5 MiB)  TX bytes:9064524 (8.6 MiB)

WizadNoNext · 04-03-2012, 05:52 AM

Your mask is completely wrong on tun0. You are in 172.16.0.0 network on tun0 and you have mask 255.255.255.255 , which should be 12-16 bits (255.224.0.0 to 255.255.255.255). in this case 172.16.8.2 is martian as it is broadcast address (impossible source address). So all your problem isn't up to martian checking in kernel, but your mask!

nikmit · 04-03-2012, 06:39 AM

Quote:

Originally Posted by WizadNoNext

Your mask is completely wrong on tun0. You are in 172.16.0.0 network on tun0 and you have mask 255.255.255.255 , which should be 12-16 bits (255.224.0.0 to 255.255.255.255). in this case 172.16.8.2 is martian as it is broadcast address (impossible source address). So all your problem isn't up to martian checking in kernel, but your mask!

The source of the dropped replies is 4.2.2.2 - the destination could be seen as a broadcast address, but that is not illegal. The interface is automatically set up by the openvpn scripts, and mostly works as expected. Can anyone tell me why all VPN traffic goes through the interface, but the ICMPs get dropped?

Code:

RX packets:106851 errors:0 dropped:0 overruns:0 frame:0                  
          TX packets:107911 errors:0 dropped:0 overruns:0 carrier:0                
          collisions:0 txqueuelen:100                                              
          RX bytes:8975484 (8.5 MiB)  TX bytes:9064524 (8.6 MiB)

WizadNoNext · 04-03-2012, 11:47 AM

Because your address is martian and address of end-point is martian as well. And end-point is sending you packets outside of your netmask (I mean end-point is outside you netmask, so it is treated as martian source). Is pretty obvious.

nikmit · 04-04-2012, 02:13 AM

You have read and are responding to the one half of my post... read again. As it is your reply does not relate to my question at all.

WizadNoNext · 04-05-2012, 01:23 AM

Code:

Mar 30 17:27:16 gate kernel: [203953.009717] martian source 172.16.8.2 from 4.2.2.2, on dev tun0

Kernel tell you here: I received packet from 4.2.2.2 with martian source 172.16.8.2
I do not say any thing about 4.2.2.2 being martian, but is say 172.16.8.2 is martian. You simply misunderstood meaning of this line you still try to solve problem which is unsolvable.
Why ICMP gets dropped?
I have an idea (could be wrong here, but my feeling say I am at least close).
ICMP is working on this network (172.16.8.2) and VPN packets comes from different IP.
Can you do tcpdump on your VPN (tun0) to confirm my theory?

nikmit · 05-10-2012, 07:51 AM

Quote:

Originally Posted by WizadNoNext

I do not say any thing about 4.2.2.2 being martian, but is say 172.16.8.2 is martian. You simply misunderstood meaning of this line you still try to solve problem which is unsolvable.

The unsolvable problem just got solved

The culprit was rp_forward. By default the kernel checks that the interface on which it receives a packet from host X is also the interface it would use to reach that host. If it is not, it drops the packet. If martian logging is enabled, it will log it else it is a silent drop.

After echo 0 > /proc/sys/net/ipv4/conf/all/rp_forward the pings seen in the tcpdump output above get accepted by the kernel and shown in the ping command output.

P.S. 172.16.8.2 is the local address of the tun0 interface - it certainly isn't martian.