[LARTC] Re: Routing that doesn't route

[LARTC] Re: Routing that doesn't route

[Julian Anastasov]

	Hello,

On Mon, 26 Nov 2001, Greg Scott wrote:

> [root@csfampls-fw /etc]# /sbin/route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> mmm.mmm.228.32  0.0.0.0         255.255.255.224 U     0      0        0 eth0
> sss.sss.200.64  mmm.mmm.228.34  255.255.255.224 UG    0      0        0 eth0
> 172.16.16.0     0.0.0.0         255.255.240.0   U     0      0        0 eth1
> 172.16.0.0      172.16.16.3     255.255.240.0   UG    0      0        0 eth1
> 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
> 0.0.0.0         206.144.228.62  0.0.0.0         UG    0      0        0 eth0
> [root@csfampls-fw /etc]#
>
> Other protocols work fine.  I tried some tests with DNS and ftp from
> St. Peter to Minneapolis and they make the round trip just fine.  Only
> ICMP ECHO REPLY packets fail the round trip.

	Are you sure TCP works between the same IPs where ICMP fails?
Can you show such traffic with tcpdump -n ?

> Here is a tcpdump trace I took from the Minneapolis firewall
> (forgive the text wrapping):
>
>
> 16:25:15.459714 < 172.16.16.2 > 172.16.0.252: icmp: echo reply

	The DNS requests you see are caused from tcpdump trying to
resolve the IPs. Always run tcpdump with -n because we don't see
the actual addresses.

	What is the value in /proc/sys/net/ipv4/conf/eth1/send_redirects ?
It is may be unrelated but run "ip route" instead of "route -n" to
see how look the routes. I'm not sure what is the pereferred source
address in each route you add by hand. On each Linux try to check with

ip route get from <SADDR> to <DADDR> iif <IN_DEVICE>

whether the packet has access to come from the specified device. You
will see where the packet should go. I assume the 3 hosts in
Minneapolis are on same subnet 172.16.16.0/20 and you expect 16.1
to/not to send ICMP redirects to redirect 16.2 to 16.3? I don't see
how such simple routing setup should fail. One of the problems
could be the conf/DEV/rp_filter settings but I don't see why it should
drop the packets. Run the above "ip route get" command.

> - Greg Scott

Regards

--
Julian Anastasov <ja@ssi.bg>


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

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

[Greg Scott]

I finally got back to that site with the routing problem with ICMP
echo reply packets.  Here is the problem:

Two subnets, 172.16.0.0/20 and 172.16.16.0/20.  They are connected
across the Internet by a VPN set up in parallel with two Linux
firewall/router systems.  The VPN servers are Windows 2000 machines,
one in each subnet.  The firewall/routers are supposed to route
traffic bound for the other side of the VPN back to the VPN servers.

Here is the problem:  When I ping from 172.16.0.nnn to any host
inside 172.16.16.nnn, the ICMP echo reply never gets past the
firewall at 172.16.16.1.  (Everyone's default gateway in the
172.16.16.nnn subnet is 16.1.)  The ICMP echo gets to the correct
host, that host replies, but the echo reply never gets past the 16.1
firewall.  The firewall/router at .16.1 is supposed to route anything 
for .0.nnn back to the VPN system at .16.3.  But it just drops these 
echo reply packets into the bitbucket.  

The 172.16.16.1 firewall uses iptables and a 2.4 kernel.  It has
the problem.  The 172.16.0.1 firewall uses ipchains and a 2.2 kernel.  
It does not have the problem.  After lots of troubleshooting, I **know**  
the problem is inside the 172.16.16.1 firewall.  Anybody inside .16.nnn
can ping anybody in .0.nnn.  The problem is pinging from .0.nnn to hosts
inside .16.nnn.  

I have tcpdump -n output showing the echo reply packets coming back
from the host being pinged, but they never get past the Linux system
to the VPN server.  I've turned off all firewall filtering rules and 
set the default policy to ACCEPT, no change in symptoms.  

Julian, you asked me to get some things:

> Are you sure TCP works between the same IPs where ICMP fails?
> Can you show such traffic with tcpdump -n ?

I've been thinking about that for the last 3 months.  From any host in
172.16.0.nnn I can telnet 172.16.16.2 53.  (16.2 is a Windows NT DNS 
server.)  I wish I knew a few quick DNS commands and I would feed a few 
and see if any kind of response comes back.  And I would capture it all 
with tcpdump -n. I always assumed that since telnet made a connection,
traffic would go both ways.  But now I am not so sure.  When I
tried telnet 172.16.16.2 21 (an ftp port), the 16.2 host immediately (and 
correctly) rejected the connection because it is not an ftp server. 

> 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

> 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

eth0 is the Internet interface.
eth1 is the trusted internal interface.

> It is may be unrelated but run "ip route" instead of "route -n" to
> see how look the routes.

[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 
172.16.0.0/20 via 172.16.16.3 dev eth1 
172.16.0.0/20 via 172.16.16.151 dev eth1 
127.0.0.0/8 dev lo  scope link 
default via aaa.bbb.228.62 dev eth0 
[root@csfampls-fw /]# 

(I disguised the public IP addresses.)

Also note the reference to .16.3 and .16.151.  This is from my
troubleshooting.
.16.3 is the real internal IP address of the VPN system.  .16.151 is the
address of the virtual device the Win2000 VPN software sets up.  I tried a
bunch of experiments yesterday with both IP addresses, no change in
symptoms.


> 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?  

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.

thanks

- Greg Scott



-----Original Message-----
From: Julian Anastasov [mailto:ja@ssi.bg]
Sent: Monday, November 26, 2001 6:27 PM
To: Greg Scott
Cc: LARTC@mailman.ds9a.nl
Subject: [LARTC] Re: Routing that doesn't route



	Hello,

On Mon, 26 Nov 2001, Greg Scott wrote:

> [root@csfampls-fw /etc]# /sbin/route -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> mmm.mmm.228.32  0.0.0.0         255.255.255.224 U     0      0        0
eth0
> sss.sss.200.64  mmm.mmm.228.34  255.255.255.224 UG    0      0        0
eth0
> 172.16.16.0     0.0.0.0         255.255.240.0   U     0      0        0
eth1
> 172.16.0.0      172.16.16.3     255.255.240.0   UG    0      0        0
eth1
> 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
> 0.0.0.0         206.144.228.62  0.0.0.0         UG    0      0        0
eth0
> [root@csfampls-fw /etc]#
>
> Other protocols work fine.  I tried some tests with DNS and ftp from
> St. Peter to Minneapolis and they make the round trip just fine.  Only
> ICMP ECHO REPLY packets fail the round trip.

	Are you sure TCP works between the same IPs where ICMP fails?
Can you show such traffic with tcpdump -n ?

> Here is a tcpdump trace I took from the Minneapolis firewall
> (forgive the text wrapping):
>
>
> 16:25:15.459714 < 172.16.16.2 > 172.16.0.252: icmp: echo reply

	The DNS requests you see are caused from tcpdump trying to
resolve the IPs. Always run tcpdump with -n because we don't see
the actual addresses.

	What is the value in /proc/sys/net/ipv4/conf/eth1/send_redirects ?
It is may be unrelated but run "ip route" instead of "route -n" to
see how look the routes. I'm not sure what is the pereferred source
address in each route you add by hand. On each Linux try to check with

ip route get from <SADDR> to <DADDR> iif <IN_DEVICE>

whether the packet has access to come from the specified device. You
will see where the packet should go. I assume the 3 hosts in
Minneapolis are on same subnet 172.16.16.0/20 and you expect 16.1
to/not to send ICMP redirects to redirect 16.2 to 16.3? I don't see
how such simple routing setup should fail. One of the problems
could be the conf/DEV/rp_filter settings but I don't see why it should
drop the packets. Run the above "ip route get" command.

> - Greg Scott

Regards

--
Julian Anastasov <ja@ssi.bg>


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

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

[Julian Anastasov]

	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/

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

[Julian Anastasov]

	Hello,

On Fri, 1 Mar 2002, Greg Scott wrote:

> > 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

	Right, just test it. The src parameter has different purpose,
it is not a key for selecting the traffic, it is a result. It will
be used for traffic originated from the 16.1 box. OTOH, it is
difficult to pass non-negotiated traffic (subnets) through the
IPSec tunnel. Make sure you can really pass traffic with any
source through this tunnel. But this is different issue.

> 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.

	Check the device flags I mentioned first.

> > 	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.

	ok, stop the ICMP redirects and see the difference.

> - Greg

Regards

--
Julian Anastasov <ja@ssi.bg>

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

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

[Greg Scott]

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/

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

[Greg Scott]

Julian, I want to thank you for your help on this one.  
After pouring over books and every google reference I 
could find, I think I finally understand what ICMP_REDIRECT 
is all about.  I'm still not clear about RP_FILTER but 
getting better.

I gathered some more data on the problem.  (The problem
was two routers connected in parallel to the inside
and outside networks.  The Linux router is everyone's
default gateway and has a route for one subnet to the 
other router.  The other router then VPNs it across the 
Internet to a remote branch office.)

The deal with ICMP_REDIRECT is, if you have more than one
router and one router gets a packet bound for somewhere, and 
that router knows there is a better first hop, that router 
will send an ICMP_REDIRECT message back to the original 
sender and the original sender is supposed to update its
routing tables.  That is what's supposed to happen.

The Linux router is running Red Hat Linux 7.1, which is
kernel 2.4-2.  I found out that ICMP Echo Reply packets 
weren't being handled right and I took a bunch of
tcpdump output showing details.

Based on Julian's advice with ICMP_REDIRECT, I got back to 
the customer site a few days ago and took advantage of an
internal DNS server named igor.  If I did telnet igor 53
from across the VPN and then sent some illegal junk to that 
DNS server, then I could ping igor across the network.  And 
sure enough, ICMP_REDIRECT set up the route in igor.

But if I removed the route in igor and tried to ping igor, 
igor would reply, but the original "pinger" never saw it  
and gor would never get an updated route from the Linux router.
tcpdump on the Linux router showed me that igor was replying, 
but the router never forwarded the reply anywhere.

The Linux router did handle my TCP port 53 stuff, but not ICMP.
So the problem had to be some kind of kernel bug around
ICMP redirects.  

I got some more time to work the problem today and finally 
reproduced the problem at my place.  Then I setup a system
with Red Hat 7.2, which uses kernel 2.4-7.  Still old, but not
as old!  I set this sytem up as a router in parallel with my
other Linux router and ran the same tests again.  This time,
everything did what it was supposed to do.

So I think the whole thing was a bug with the 2.4-2 kernel.

So for people running the 2.4-2 kernel with routing turned
on and in parallel with another router, one workaround is
to send any kind of TCP packet first to the other side, which
will make ICMP_REDIRECT do its thing.

A better workaround - as Julian pointed out:

echo 1 > /proc/sys/net/ipv4/conf/eth0/send_redirects
echo 1 > /proc/sys/net/ipv4/conf/eth1/send_redirects

An even better fix - upgrade from Red Hat 7.1 to 7.2.  

And maybe the best fix is to just bite the bullet
and upgrade to the latest stable kernel.  That's the
next challenge I'm going to work on!

thanks

- 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/

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

[Julian Anastasov]

	Hello,

On Wed, 1 May 2002, Greg Scott wrote:

> is all about.  I'm still not clear about RP_FILTER but
> getting better.

	Simple thing: IP or ARP packet is accepted only if
there is a route in reverse direction, i.e. when the addresses
are reversed. Example:

packet 10.0.0.1->10.0.0.2 is coming from eth0 and we have a
route to 10.0.0.1 via eth0, so the packet is accepted from the
reverse path protection (rp_filter) set on eth0. If this
packet comes from eth1 (again with rp_filter=1) then it will
be dropped because we already have a route via eth0. As
result, packets from 10.0.0.0/24, for example, should come
only from eth0. In any other case, they will be dropped from
other devices with rp_filter protection and always allowed
from devices without such protection.

	The rp_filter is also explained here:

http://lartc.org/HOWTO//cvs/2.4routing/html/c1182.html#AEN1188

> reproduced the problem at my place.  Then I setup a system
> with Red Hat 7.2, which uses kernel 2.4-7.  Still old, but not
> as old!  I set this sytem up as a router in parallel with my
> other Linux router and ran the same tests again.  This time,
> everything did what it was supposed to do.
>
> So I think the whole thing was a bug with the 2.4-2 kernel.

	Yes, testing with latest kernel should be the first
thing to try :)

> thanks
>
> - Greg

Regards

--
Julian Anastasov <ja@ssi.bg>

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