On Fri, 27 Sep 2002 08:22:02 -0700
"Matthew Schalit" <[EMAIL PROTECTED]> wrote:
> Chad Carr wrote:
> > Hello routing and tunneling guys and gals! I have a tunneling quandry
> > for ye.
> >
> > I am doing an implementation of mobile ip and have finally solidified
> > all of the protocol bits to implement a foreign agent, and have come
> > to the part where I need to accept ip-in-ip tunneled packets for a
> > mobile node, detunnel them, and deliver them to him. I am using the
> > kernel ipip.o module for this, and have configured the tunnel as
> > follows:
> >
> > __________ _____________ ___________
> > | | | | | |
> > |home agent|===(router)===>|foreign agent|------->|mobile node|
> > |__________| |_____________| |___________|
> >
> >
> > home agent ip - 172.24.8.99
> > foreign agent ip - 172.24.20.104
> > mobile node ip - 172.24.8.24 (on the foreign network)
>
>
>
> I question the ip addresses below....
>
>
>
>
> >
> > I am not in control of the home agent, but I have verified with a
> > sniffer that he is sending me well-formed ip-in-ip packets for the
> > mobile node, plus he works with anothe foreign agent that I have, so
> > he is not the problem.
> >
> > foreign agent configuration:
> >
> > # bring up tunnel device
> > ip tunnel add mode ipip # (default tunnel tunl0; local *->remote *)
> >
> > # add static arp table entry since mobile node can't reply
> > ip neigh add 172.24.8.24 lladdr 00:00:0d:2f:a0:b0 dev eth0 nud perm
> >
> > # add static host route
> > ip route add 172.24.8.24 dev eth0
>
>
>
>
> Is 172.24.8.24 really connected to eth0 or is the it eth1?
My email was unclear on this. There is really only one interface in the
foreign agent. The picture should look more like this:
___________
| |
|mobile node|<-----|
__________ ________|___________| |
| | | |
|home agent|===(router)===| _____________ |
|__________| |=======>| | |
|foreign agent|----|
|_____________|
subnet 172.24.8.0/24 subnet 172.24.20.0/22
That is, the mobile node and the foreign agent are on the same segment on
the right-hand side of the router (the foreign agent is on the "right"
segment, conceptually, and the mobile node is on the "wrong" segment,
conceptually). There is a unicast ip-in-ip tunnel between the home agent
and the foreign agent (on different segments; the router is needed to get
packets back and forth on the tunnel between home agent and foreign agent)
>
> >
> > I have verified the following:
> >
> > 1) The packets are getting delivered to the foreign agent;
> > 2) The packets are being accepted by tunl0 and processed;
> > 3) They are the expected size (the size of the inner ip packet);
> > 4) They are not being delivered anywhere outside the box.
>
>
>
> But it seems like you haven't enabled logging all packets on
> the foreign agent that come from the home agent or are destined
> for the home agent. I find adding those types of firewall rules
> essential to these routing jobs. Seriously. Log them packys.
>
> Then you'd see if the traffic is even moving out eth0 on the
> foreign agent on its way to the remote node.
Okay, I added the following rules to the firewall:
iptables -A PREROUTING -t mangle -j LOG
iptables -A INPUT -t mangle -j LOG
iptables -A FORWARD -t mangle -j LOG
So, new information: I see the tunneled packet coming in on both
PREROUTING and INPUT on interface eth0, as it should be. I then see the
_unwrapped_ packet coming in on INPUT on interface tunl0.
The destination address of the unwrapped packet is 172.24.8.24. I figure,
according to the rules in Rusty's unreliable guide on iptables, that the
packet should hit the FORWARD chain next (since it is not destined to the
foreign agent itself), but is somehow failing some internal sanity check
and getting dropped. After PREROUTING, a packet should hit either INPUT
or FORWARD, correcto?
>
> > I figure the following bits are true:
> >
> > The foreign agent is holding a copy of the ip packet addressed to the
> > mobile node. He may do one of the following: a) assume that the
> > packet is for delivery on the local link, look up the ip in the
> > arp table, and deliver it to the mobile node b) hit the routing table
> > again and see the host route, see that it is directly connected,
> > look up the ip in the arp table, and deliver it to the mobile
> > node. c) drop the packet
> >
> > Obviously, given the way I have configured the box, I believe that "b"
> > should be what is happening. However, it seems plain that "c" is the
> > option that has been chosen by the tunl0 device.
> >
> > I am obviously missing something quite overt, so I thought that one of
> > you guys might be able to see what I can't.
>
>
>
> If you're running a /16 netmask all over, and you didn't tell
> us that, then the packets should be accepted unless they are
> dropped by the firewall rules or the config is wrong. At first
> glance I don't spot anything wrong, but don't trust that :)
Not a /16 netmask. The 172.24.0.0/16 is subnetted. 172.24.8.0/24 on the
left of the router and 172.24.20.0/22 on the right of the router. I also
have no firewall rules except for those enabling logging. The chains are
completely flushed.
>
> If the netmask is not /16 all around, then what have you done
> on the foreign agent to tell it that it's bridging the two networks,
> namely > foreign agent ip - 172.24.20.104
> > mobile node ip - 172.24.8.24
The foreign agent is not a bridge; there is a router between the home
agent and foreign agent.
> It'd help if you pasted in any relevant messages in from the foreign
> agent syslog showing the trail of the packets being accepted and moving
> in and out eth cards. Any masqing/forwarding enabled on the Foreign
> Host?
I don't have the logs at home this weekend, but hopefully the description
above of the packets I am receiving and their devices clarifies this.
I have done:
echo 1 > /proc/sys/net/ipv4/ip_forward
>
> Well, got to walk the pooch. Hope I brought something up
> that might be useful, Matt
>
Thanks for your help and input. I appreciate your time ready my hairy
(and somewhat inaccurate) diagrams.
--
------------------------------------------------------------------------
Chad Carr [EMAIL PROTECTED]
------------------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
------------------------------------------------------------------------
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
