On Sat, 2007-02-10 at 20:10 -0500, Brian J. Murrell wrote: > On Sat, 2007-02-10 at 13:31 -0800, Tom Eastep wrote: > > > > That's consistent with what we're seeing. > > > > The best way to work around this is to configure applications on the > > firewall so that they use the local IP address that corresponds to the > > interface that you want them to use. > > See, this is all a red herring I think. I think the outgoing address > and the return address and the interface they are coming back in on is > all correct. I think the SNAT/masq'ing to ensure the correct source > address is being set is working fine and as for the routing back given > the source address I specify, that has to be working or the Internet > would be really broken if it were not.
OK. So it's not so much a red herring, but it is something very
strange.
Here the tcpdump on my eth1 nic who's address is gw-eth1:
$ grep gw-eth1 /etc/hosts
72.38.184.236 gw-eth1
20:19:13.409971 IP gw-eth1.1194 >
CPE00a0c98cb9ff-CM000a73a15345.cpe.net.cable.rogers.com.1194: UDP, length 124
20:19:13.433470 IP CPE00a0c98cb9ff-CM000a73a15345.cpe.net.cable.rogers.com.1194
> gw-eth1.1194: UDP, length 124
20:19:14.413857 IP gw-eth1.1194 >
CPE00a0c98cb9ff-CM000a73a15345.cpe.net.cable.rogers.com.1194: UDP, length 124
20:19:14.437204 IP CPE00a0c98cb9ff-CM000a73a15345.cpe.net.cable.rogers.com.1194
> gw-eth1.1194: UDP, length 124
20:19:15.414026 IP gw-eth1.1194 >
CPE00a0c98cb9ff-CM000a73a15345.cpe.net.cable.rogers.com.1194: UDP, length 124
20:19:15.439276 IP CPE00a0c98cb9ff-CM000a73a15345.cpe.net.cable.rogers.com.1194
> gw-eth1.1194: UDP, length 124
20:19:16.413976 IP gw-eth1.1194 >
CPE00a0c98cb9ff-CM000a73a15345.cpe.net.cable.rogers.com.1194: UDP, length 124
20:19:16.437514 IP CPE00a0c98cb9ff-CM000a73a15345.cpe.net.cable.rogers.com.1194
> gw-eth1.1194: UDP, length 124
All source and destination addresses are correct. Packets are leaving
and coming back properly addressed. Yet:
Feb 10 20:19:09 gw.ilinx kernel: ll header:
00:a0:24:2a:1f:72:00:13:5f:07:97:05:08:00
Feb 10 20:19:14 gw.ilinx kernel: printk: 4 messages suppressed.
Feb 10 20:19:14 gw.ilinx kernel: martian source 66.11.173.224 from
74.111.215.93, on dev eth1
Feb 10 20:19:14 gw.ilinx kernel: ll header:
00:a0:24:2a:1f:72:00:13:5f:07:97:05:08:00
Feb 10 20:19:19 gw.ilinx kernel: printk: 4 messages suppressed.
Feb 10 20:19:19 gw.ilinx kernel: martian source 66.11.173.224 from
74.111.215.93, on dev eth1
Feb 10 20:19:19 gw.ilinx kernel: ll header:
00:a0:24:2a:1f:72:00:13:5f:07:97:05:08:00
Feb 10 20:19:24 gw.ilinx kernel: printk: 4 messages suppressed.
Feb 10 20:19:24 gw.ilinx kernel: martian source 66.11.173.224 from
74.111.215.93, on dev eth1
Feb 10 20:19:24 gw.ilinx kernel: ll header:
00:a0:24:2a:1f:72:00:13:5f:07:97:05:08:00
And:
# ip route get 74.111.215.93
74.111.215.93 via 192.168.200.1 dev ppp0 src 66.11.173.224
cache mtu 1452 advmss 1412 metric 10 64
To give some numbers to some names:
$ grep gw-eth1 /etc/hosts
72.38.184.236 gw-eth1
$ host CPE00a0c98cb9ff-CM000a73a15345.cpe.net.cable.rogers.com
CPE00a0c98cb9ff-CM000a73a15345.cpe.net.cable.rogers.com has address
74.111.215.93
# ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:A0:24:2A:1F:72
inet addr:72.38.184.236 Bcast:72.38.185.255 Mask:255.255.254.0
[EMAIL PROTECTED] shorewall]# arp -an
? (72.38.184.1) at 00:13:5F:07:97:05 [ether] on eth1
So I'd say packets are definitely addressed correctly at my eth1
demarcation.
And now, at this moment, it's again working and here we can see:
# ip route get 74.111.215.93
74.111.215.93 via 192.168.200.1 dev ppp0 src 72.38.184.236
cache mtu 1452 advmss 1412 metric 10 64
So I am convinced that the problem is the flip-flopping of the active
default route to achieve load balancing. And I consider this a bug in
the rp_filter functionality. I'd say that every default route needs to
be examined when doing reverse-path analysis, not just the one that is
currently active. Even without the kind of trickery we are using to
force the use of one of the default routes, there will always be a race
between when a packet leaves a machine and when the machine decides to
"flip" the active default route. I wonder if I should bug report this
and see how much traction I get.
As for the 66.11.173.224 (i.e. the address of the ppp0 interface)
appearing in the martian log entry source addresses, I'm beginning to
think that that is just the error message printing that for whatever
reason. Perhaps it's trying to tell us the interface it would have
expected the packet on -- in a roundabout, obtuse way. I don't think
it's bad routing of the packet back to my machine, or even rewriting of
the destination address of the packet as I once suspected.
b.
--
My other computer is your Microsoft Windows server.
Brian J. Murrell
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
