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. |
Quote:
|
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'. |
Quote:
Code:
echo 0 >/proc/sys/net/ipv4/conf/tun0/log_martians Quote:
|
Quote:
Code:
root@box:~# ifconfig tun0 |
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!
|
Quote:
Code:
RX packets:106851 errors:0 dropped:0 overruns:0 frame:0 |
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.
|
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.
|
Code:
Mar 30 17:27:16 gate kernel: [203953.009717] martian source 172.16.8.2 from 4.2.2.2, on dev tun0 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? |
Quote:
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 07:20 AM. |