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/