[luv-main] Routing change handling in recent kernels.
I'm hoping somebody can help me understand what has changed in recent kernels, with regard to routing. I'm having a problem with Centos 6 hosts (and the same problem I had with a Ubuntu 10.10 host), that I dont have with Centos5 hosts. I can only conclude that its changes in IP handling that may have occurred with these later kernels. (Or changes in IP kernel configuration in these later distros?) I have this configuration: * Firewall Router eth0 10.10.3.1/26 PPOEServer (running over eth0) - handing out public addresses to pppoe clients * Centos 5 hosts (many) eth0 10.10.3.0/26 - (with a route 10/8 via this interface) ppp0 (running over eth0) - getting a A.B.C.x address (this is a public accessible address) * My laptop eth0/wlan0 10.10.3.128/26 (a different interface on the router) My laptop has been very successful in communicating with C5 hosts via eth0 address and ppp0 address. Specifically, on my laptop, when I connect to A.B.C.x, the packet arrives on the host on the ppp0 interface, and the reply goes out the eth0 interface (because of a default 10/8 route via that interface). Obviously if I talk to the host on its 10.10.3.0/26 address, the packet arrives and leaves via the eth0 interface. I implemented both Ubuntu 10.10 and Centos 6 servers with exactly the same configuration, ie: eth0 10.10.3.0/26 ppp0 (running over eth0) - getting A.B.C.x address However, I cannot talk to the hosts via the ppp0 interface, when I'm on a network that the reply would go via the eth0 interface. Specifically, if the packet arrives on the ppp0 interface and *would* leave via the eth0 interface, it appears as if the host is not even processing the packet. iptables confirms that it doesnt count the packets coming in. Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 all -- ppp0 * 0.0.0.0/0 0.0.0.0/0 If I communicate with the host, where the packet arrives and leaves on the same interface - no problem. If I change my routing so that access to my laptop (10.10.10.128/26) is back via the ppp0 interface - then all is good (but not want I want) - if I access the host via its 10.10.3.0/26 address, then no problems either - again not really what I want. Here's some network tracing to show whats going on... (And yes, all this is done with firewall rules turned off - to make sure that there wasnt an offending rule) Here is what I see (if I ping the host via its A.B.C.x address from my laptop 10.10.3.130) Router (pppoes interface): 10:41:45.461588 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 1, length 64 10:41:46.461205 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 2, length 64 10:41:47.460768 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 3, length 64 10:41:48.461881 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 4, length 64 Host: (ppp0) (ICMP echo, but no reply) listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 10:41:44.220727 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 1, length 64 10:41:45.219741 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 2, length 64 10:41:46.218733 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 3, length 64 10:41:47.219735 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 4, length 64 Host: (eth0) (only the PPPoE packets - no reply) listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 10:41:44.219726 PPPoE [ses 0x4b] IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 1, length 64 10:41:45.219005 PPPoE [ses 0x4b] IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 2, length 64 10:41:46.218227 PPPoE [ses 0x4b] IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 3, length 64 10:41:47.218992 PPPoE [ses 0x4b] IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 4, length 64 And for info, here's hosts routing table: 172.31.3.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.10.3.0 0.0.0.0 255.255.255.224 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0 10.0.0.0 10.10.3.1 255.0.0.0 UG 0 0 0 eth0 0.0.0.0 172.31.3.1 0.0.0.0 UG 0 0 0 ppp0 What's changed in the new kernels - or the new distro versions? ...deon
On 15/09/2011, at 11:08, Deon George <dgeorge@au1.ibm.com> wrote:
My laptop has been very successful in communicating with C5 hosts via eth0 address and ppp0 address. Specifically, on my laptop, when I connect to A.B.C.x, the packet arrives on the host on the ppp0 interface, and the reply goes out the eth0 interface (because of a default 10/8 route via that interface). Obviously if I talk to the host on its 10.10.3.0/26 address, the packet arrives and leaves via the eth0 interface.
centos 5 obviously has the sysctl rp_filter disabled, and the others have enabled it. rp_filter will check incoming source address against its own interface addresses, to try and prevent address spoofing. disable it in /etc/sysctl.conf and you should be good
That was it - thank you :) ...deon hannah commodore <hannah@tinfoilhat.net> wrote on 15/09/2011 13:45:45:
centos 5 obviously has the sysctl rp_filter disabled, and the others have enabled it.
rp_filter will check incoming source address against its own interface addresses, to try and prevent address spoofing.
disable it in /etc/sysctl.conf and you should be good
hannah commodore wrote:
On 15/09/2011, at 11:08, Deon George <dgeorge@au1.ibm.com> wrote:
My laptop has been very successful in communicating with C5 hosts via eth0 address and ppp0 address. Specifically, on my laptop, when I connect to A.B.C.x, the packet arrives on the host on the ppp0 interface, and the reply goes out the eth0 interface (because of a default 10/8 route via that interface). Obviously if I talk to the host on its 10.10.3.0/26 address, the packet arrives and leaves via the eth0 interface.
centos 5 obviously has the sysctl rp_filter disabled, and the others have enabled it.
rp_filter will check incoming source address against its own interface addresses, to try and prevent address spoofing.
disable it in /etc/sysctl.conf and you should be good
RPF is a Good Thing. Rather than disabling it entirely, I recommend turning it off only on interfaces where it doesn't DTRT. Further, recent kernels have rp_filter=2 (i.e. "weak" RPF); if =1 doesn't work, try =2 before =0.
participants (3)
-
Deon George -
hannah commodore -
Trent W. Buck