RE: [LARTC] Re: Routing that doesn't route

[Greg Scott <GregScott@InfraSupportEtc.com>]

Thanks Julian.

> ip route add 172.16.0.0/20 via 172.16.16.3 dev eth1 src 172.16.16.1

That's not really what I want to do.  I want everthing bound for the
0.0/20 subnet, no matter the source, to route thru 16.3.  16.1 is the
firewall/router and it might initiate some packets, but there are a 
bunch of hosts in 16.0 that will also initiate packets.  The echo reply
packets that are giving me problems should be just like any other IP
packet shouldn't they?  I don't want to filter or redirect or masquerade
or shape any of this, just route it.

Note the problem is in replying to anybody in 0.0/20 - I use 0.252 
because it's a convenient host.  My test packets come from 16.2 (they 
could come from anybody in 16.0/20), replying to 0.252.  Since the 
default gw from 16.2 is 16.1, the echo reply should flow like this:  

16.2 --> 16.1 --> 16.3 --> (VPN stuff) --> 0.251 --> 0.252.  

Since 16.1 has a specific route to 16.3 for anything with destination 
0.0/20, it should just forward it back out eth1 and over to 16.3.  But 
it doesn't - it just bitbuckets the dad-blamed thing!

That's why I think I'm looking at a kernel bug.  Note the physical
path inside the Linux box.  The packet comes in eth1 and I want to
sent it back out eth1.  I think that's the key.  I am trying to route
a packet out the same interface on which it came in.

> 	If clearing all send_redirects and rp_filter flags to 0 and
> using correct preferred source IP addresses does not help then you
> hit a kernel bug. Try with recent kernel.

But this all works well with similar testing using the 2.2 kernel on 
the other end.  It's the 2.4.2-2 kernel that ships with Red Hat 7.1 
giving me problems.  

> you are trying alternative routes which work only by using my patches,
> the following can't work in plain kernel:

>> 172.16.0.0/20 via 172.16.16.3 dev eth1
>> 172.16.0.0/20 via 172.16.16.151 dev eth1

Apologies for that one.  That was from a bunch of troubleshooting
yesterday and only yesterday.  Here is the way it is normally setup:

[root@csfampls-fw gregs]# /sbin/ip route show
aaa.bbb.228.32/27 dev eth0  proto kernel  scope link  src aaa.bbb.228.33 
ccc.ddd.200.64/27 via aaa.bbb.228.34 dev eth0 
172.16.16.0/20 dev eth1  proto kernel  scope link  src 172.16.16.1 
172.16.0.0/20 via 172.16.16.3 dev eth1 
127.0.0.0/8 dev lo  scope link 
default via aaa.bbb.228.62 dev eth0 

- Greg



-----Original Message-----
From: Julian Anastasov [mailto:ja@ssi.bg]
Sent: Thursday, February 28, 2002 4:49 PM
To: Greg Scott
Cc: LARTC@mailman.ds9a.nl; Patsy Rossow (E-mail)
Subject: RE: [LARTC] Re: Routing that doesn't route



	Hello,

On Thu, 28 Feb 2002, Greg Scott wrote:

> > What is the value in /proc/sys/net/ipv4/conf/eth1/send_redirects ?
>
> [root@csfampls-fw /]# more /proc/sys/net/ipv4/conf/eth1/send_redirects
> 1

	This is one of the values you can try to alter. Try to set
both all/send_redirects and eth1/send_redirects to 0.

> > On each Linux try to check with
> > ip route get from <SADDR> to <DADDR> iif <IN_DEVICE>
>
> [root@csfampls-fw /]#
> [root@csfampls-fw /]# /sbin/ip route get from 172.16.16.2 to 172.16.0.252
> iif eth1
> 172.16.0.252 from 172.16.16.2 via 172.16.16.3 dev eth1  src 172.16.16.1
>     cache <src-direct,redirect>  mtu 1500 iif eth1

	OK, traffic is not dropped from rp_filter. But this box
should send ICMP redirects (note the "redirect" flag), i.e. it
redirects traffic from 16.2 to 0.252 through 16.3. If you try
with {all,eth1}/send_redirects=0 the traffic will be silently
accepted and then forwarded to 16.3.

> [root@csfampls-fw /]#
> [root@csfampls-fw /]# /sbin/ip route show
> aaa.bbb.228.32/27 dev eth0  proto kernel  scope link  src aaa.bbb.228.33
> ccc.ddd.200.64/27 via aaa.bbb.228.34 dev eth0
> 172.16.16.0/20 dev eth1  proto kernel  scope link  src 172.16.16.1

you are trying alternative routes which work only by using my patches,
the following can't work in plain kernel:

> 172.16.0.0/20 via 172.16.16.3 dev eth1
> 172.16.0.0/20 via 172.16.16.151 dev eth1

	Note also that the above routes should have a preferred
source IP. Avoid using the "route" tool in advanced routing setups.
Try with "ip":

ip route add 172.16.0.0/20 via 172.16.16.3 dev eth1 src 172.16.16.1

> 127.0.0.0/8 dev lo  scope link

same here, make sure all your routes have right preferred source IP:

> default via aaa.bbb.228.62 dev eth0

	In the other case you risk the kernel to select wrong IP address
for your originating or masqueraded traffic.

> [root@csfampls-fw /]#
>
> > One of the problems
> > could be the conf/DEV/rp_filter settings but I don't see why it should
> > drop the packets.
>
> How do I look at these and what are they?

/proc/sys/net/ipv4/conf/{all,eth1}/rp_filter

but it seems it's not a problem. Of course, try to set all them
to 0 for the test.

> Every setting I can think of so far looks good.  What am I
> missing????  Or is there a bug?  Note, this is happening in two completely
> unrelated places.  But it could be that I set up both places with the same
> mistake.

	If clearing all send_redirects and rp_filter flags to 0 and
using correct preferred source IP addresses does not help then you
hit a kernel bug. Try with recent kernel.

> thanks
>
> - Greg Scott

Regards

--
Julian Anastasov <ja@ssi.bg>

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/