LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 03-30-2012, 09:30 AM   #1
nikmit
Member
 
Registered: May 2011
Location: Nottingham, UK
Distribution: Debian
Posts: 178

Rep: Reputation: 34
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.
 
Old 03-30-2012, 10:42 AM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,409
Blog Entries: 55

Rep: Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582Reputation: 3582
Quote:
Originally Posted by nikmit View Post
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.
 
Old 03-30-2012, 11:37 AM   #3
nikmit
Member
 
Registered: May 2011
Location: Nottingham, UK
Distribution: Debian
Posts: 178

Original Poster
Rep: Reputation: 34
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'.

Last edited by nikmit; 03-30-2012 at 11:42 AM.
 
Old 03-31-2012, 12:28 PM   #4
WizadNoNext
Member
 
Registered: Nov 2009
Posts: 131

Rep: Reputation: 9
Quote:
Originally Posted by nikmit View Post
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.

Last edited by WizadNoNext; 03-31-2012 at 12:34 PM.
 
1 members found this post helpful.
Old 04-02-2012, 02:49 AM   #5
nikmit
Member
 
Registered: May 2011
Location: Nottingham, UK
Distribution: Debian
Posts: 178

Original Poster
Rep: Reputation: 34
Quote:
Originally Posted by WizadNoNext View Post
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)
 
Old 04-03-2012, 05:52 AM   #6
WizadNoNext
Member
 
Registered: Nov 2009
Posts: 131

Rep: Reputation: 9
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!
 
Old 04-03-2012, 06:39 AM   #7
nikmit
Member
 
Registered: May 2011
Location: Nottingham, UK
Distribution: Debian
Posts: 178

Original Poster
Rep: Reputation: 34
Quote:
Originally Posted by WizadNoNext View Post
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)
 
Old 04-03-2012, 11:47 AM   #8
WizadNoNext
Member
 
Registered: Nov 2009
Posts: 131

Rep: Reputation: 9
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.
 
Old 04-04-2012, 02:13 AM   #9
nikmit
Member
 
Registered: May 2011
Location: Nottingham, UK
Distribution: Debian
Posts: 178

Original Poster
Rep: Reputation: 34
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.

Last edited by nikmit; 04-04-2012 at 02:15 AM.
 
Old 04-05-2012, 01:23 AM   #10
WizadNoNext
Member
 
Registered: Nov 2009
Posts: 131

Rep: Reputation: 9
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?
 
Old 05-10-2012, 07:51 AM   #11
nikmit
Member
 
Registered: May 2011
Location: Nottingham, UK
Distribution: Debian
Posts: 178

Original Poster
Rep: Reputation: 34
Quote:
Originally Posted by WizadNoNext View Post
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
How to drop packets satya_seth Linux - Newbie 5 07-06-2009 04:30 AM
dropping of ICMP packets from martian sources kishku Linux - Networking 2 10-19-2004 08:06 PM
How to intentionally drop packets? imarunner Linux - Networking 5 12-31-2003 08:10 AM
how to drop all packets to one host with the default rule of accept dan5009 Linux - Security 1 08-20-2003 05:55 PM
why does the kernel drop packets ? mr.moto Linux - Networking 3 12-08-2002 12:47 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 11:54 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration