Thanks to everyone who helped me out with this, both on and off list. I am posting a follow-up since I finally got it worked out yesterday.
Here is a re-posting of the clarified version of the problem: On Sun, 29 Sep 2002 14:05:44 -0700 "Chad Carr" <[EMAIL PROTECTED]> wrote: > Thanks very much for your patience. This diagram is trying to detail > something that doesn't happen usually in nature, which is the existence > of a mobile node on the "wrong" subnet, with two computers in > cooperation(home agent and foreign agent) attempting to get packets to > it. > > > I'll try again: > > 172.24.8.1/24 172.24.20.1/22 > ________ ^________^ __________ > | switch |-------| router |-------| switch | > |________| |________| |__________| > | | | > ______|_____ _____________|_ _|___________ > | | | | | | > | home agent | | foreign agent | | mobile node | > |____________| |_______________| |_____________| > 172.24.8.99/24 172.24.20.104/22 172.24.8.24/24 > > All links are CAT5 ethernet. Home agent, foreign agent and mobile node > are each separate, regular PC hosts with one NIC (eth0) and one IP > address each. > > The titles "home agent" and "foreign agent" are simply relative to the > mobile node. The home agent "catches" packets destined for the mobile > node (via proxy arp), tunnels them through the router to the foreign > agent, who has agreed to detunnel them and deliver them (via the mobile > node's known _hardware_ address) to the mobile node. The mobile node > really "belongs" on the same network as the home agent. The foreign > agent is not a bridge - it knows the ethernet address of the mobile node > and has a host route to it that indicates that it is on the same link > (see below). > > The IP-in-IP tunnel is between the home agent and the foreign agent. I > have verified that the packets routing between them are properly formed > and have correct checksums in all the right places. > > I have verified that the foreign agent is receiving the tunneled packet > on eth0 by logging all packets seen on PREROUTING and INPUT using the > following rules: > > iptables -A PREROUTING -t mangle -j LOG > iptables -A INPUT -t mangle -j LOG > > I also see the de-tunneled packet arriving on tunl0 via the PREROUTING > chain. I have also added the following rule to track packets on the > FORWARD chain, which is where I think the de-tunneled packet should go > next. > > iptables -F FORWARD -t mangle -j LOG > > I see nothing. I am sorry I do not have the logs at home. I can send > them on Monday. The following are reconstructions of the setup on the > foreign agent to the best of my memory. > <snip; for brevity> > > The packet and byte count increment properly when packets are received. > The byte count increases by the size of the _inner_ packet. > Two things were eluding me, which I had tried independently, but not together until yesterday. 1) Netfiliter does not like receiving ip packets from interfaces that do not have any ip address configured. Although I had shown this... > 19: tunl0@NONE: <NOARP> mtu 1480 qdisc noop > link/ipip 0.0.0.0 brd 0.0.0.0 > inet 172.24.8.104/32 scope global tunl0 as the output of ip addr, it was something that I was playing with at the time, and apparently did not have set when I tried number 2 below. It shows the value of using make as a system integration tool, if simply for repeatability purposes. If I had been using make, I wouldn't have overlooked setting the ip address of the device, ever! 2) Linux, by defaults set in Debian (and therefore Bering), does not like receiving ip packets from a given source address on an interface that it would not choose for sending to that address. E.g. I was receiving packets from the home agent on tunl0, but if I had to send to him, I would have chosen eth0 to do so. See routing table: > 172.24.8.24 dev eth0 scope link > 172.24.20.0/22 dev eth0 proto kernel scope link src 172.24.20.104 > default via 172.24.20.1 dev eth0 If I were using the mobile ip concept called "reverse tunneling," which basically uses the source address to choose the tunnel device and gateway for routing the outbound packets, I probably would not have seen this problem. In mobile ip, the default behavior is that outbound packets (from the mobile node) are routed normally, while inbound packets (to the mobile node) are routed in triangular fashion, through the home agent, tunneled to the foreign agent, then detunneled and delivered on the last hop by the foreign agent. I was doing the default behavior, so packets destined to the home agent would have chosen the default route on eth0 and been delivered to the gateway, but tunneled packets coming from the home agent were arriving on the tunl0 interface. I had to set /proc/sys/net/ipv4/conf/*/rp_filter off by modifying "spoofprotect=yes" to "spoofprotect=no" in the /etc/network/options file to stop this behavior. You would think that these two problems would have been more evident to me, since I had to deal with them with the ipsec stuff, but it was the combination that got me. Thanks again. -- ------------------------------------------------------------------------ Chad Carr [EMAIL PROTECTED] ------------------------------------------------------------------------ ------------------------------------------------------- This sf.net email is sponsored by: DEDICATED SERVERS only $89! Linux or FreeBSD, FREE setup, FAST network. Get your own server today at http://www.ServePath.com/indexfm.htm ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
