LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   How to disable the default drop of martian packets? (https://www.linuxquestions.org/questions/linux-networking-3/how-to-disable-the-default-drop-of-martian-packets-937275/)

nikmit 03-30-2012 10:30 AM

How to disable the default drop of martian packets?
 
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 11:42 AM

Quote:

Originally Posted by nikmit (Post 4640697)
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 12:37 PM

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 01:28 PM

Quote:

Originally Posted by nikmit (Post 4640697)
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 03:49 AM

Quote:

Originally Posted by WizadNoNext (Post 4641537)
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 06: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 07:39 AM

Quote:

Originally Posted by WizadNoNext (Post 4643449)
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 12:47 PM

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 03: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 02: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 08:51 AM

Quote:

Originally Posted by WizadNoNext (Post 4645150)
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.


All times are GMT -5. The time now is 04:17 PM.