IPv6, TUN, routing
in [Linux Networking]
|
Prev: linux ad-hoc and managed mode wireless networking
Next: Open Source Programs (SysAdmin and NetAdmin)
From: Olof-Joachim Frahm on 21 Mar 2010 18:04 Hello, I've got a problem configuring a computer as a border router for a TUN device. The program for the TUN device logs packets/pings correctly on the local host, but doing the same in the network doesn't work at all. Basically the TUN device will act as an endpoint for another network and (at the moment) doesn't perform any work except forwarding packets. I've got two machines: machine A, which runs router advertisements with radvd (and the program for the TUN device (with prefix fec0::/64)), and machine B as a test machine. Forwarding is enabled. Both test computers have link-local addresses (fe80::.../64) and can ping each other under those addresses (while providing ping6 with an interface name). The ::/0 entry is sent to "lo", so other (IPv6) hosts and the internet (e.g. ipv6.google.com) aren't reachable through it. Machine A, when run with the TUN program, then has the routing entry: fec0::/64 :: U 256 0 0 tun0 and this works, so (locally) pinging some address in that range appears in the program. Now, when I run radvd with the configuration file: interface eth1 { AdvSendAdvert on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; AdvRouteLifetime 30; prefix fec0::/64 { AdvOnLink on; AdvAutonomous on; }; }; , machine B gets two additional routing entries: fec0::/64 :: UAe 256 0 0 eth1 ::/0 fe80::217:a4ff:fe1a:e3af UGDAe 1024 0 1 eth1 ^-- Machine A , which I assume are correct(?). Now pinging some address in the fec0::/64 range doesn't work on machine B, the packets just vanish with "Address unreachable"; on machine A, using tcpdump, no packets come through. I'd be very grateful for any hints and ideas to make this work (or why this can't work for whatever reason). Regards, Olof -- The world is burning. Run.
From: Pascal Hambourg on 22 Mar 2010 07:23 Hello, Olof-Joachim Frahm a �crit : > > I've got a problem configuring a computer as a border router for a TUN > device. The program for the TUN device logs packets/pings correctly > on the local host, but doing the same in the network doesn't work at > all. Basically the TUN device will act as an endpoint for another > network and (at the moment) doesn't perform any work except forwarding > packets. > > I've got two machines: machine A, which runs router advertisements with > radvd (and the program for the TUN device (with prefix fec0::/64)), and > machine B as a test machine. Forwarding is enabled. Note that the definition of fec0::/10 as a site-local prefix has been deprecated for years and is now reserved (cf. RFC 3879). If you do not have an available global prefix, you can use a ULA prefix (Unique Local Addresses, cf. RFC 4193) instead. A web-based ULA prefix generator is available at <http://www.kame.net/~suz/gen-ula.html>. > Machine A, when run with the TUN program, then has the routing entry: > > fec0::/64 :: U 256 0 0 tun0 > > and this works, so (locally) pinging some address in that range appears > in the program. > > Now, when I run radvd with the configuration file: > > interface eth1 { > AdvSendAdvert on; > MinRtrAdvInterval 3; > MaxRtrAdvInterval 10; > AdvRouteLifetime 30; > > prefix fec0::/64 { > AdvOnLink on; > AdvAutonomous on; > }; > }; > > , machine B gets two additional routing entries: > > fec0::/64 :: UAe 256 0 0 eth1 > ::/0 fe80::217:a4ff:fe1a:e3af UGDAe 1024 0 1 eth1 > ^-- Machine A > > , which I assume are correct(?). Well... according to the radvd configuration, it is. > Now pinging some address in the fec0::/64 range doesn't work on machine > B, the packets just vanish with "Address unreachable"; This is a basic prefix assignment mismatch. Machine A thinks that the prefix is directly attached to the TUN interface (diret route), but sends ICMPv6 Router Advertisement messages telling that the prefix is directly attached to the ethernet link. Because of these Router Advertisement messages machine B thinks that the prefix is directly attached to the ethernet link, which is wrong. So machine B sends ICMPv6 Neighbour Solicitation messages for addresses within the prefix on the ethernet link instead of using the default route defining machine A as the router, which would be the right thing to do. My suggestion : Define a different prefix for the ethernet link. Have radvd advertise this prefix instead of the TUN prefix. No need to advertise a route for the TUN prefix, the default route will handle it just fine. Another approach is based on Neighbour Discovery proxying, but that sucks. Do not use it unless you have no choice. > on machine A, using tcpdump, no packets come through. Not even Neighbour Solicitation ICMPv6 messages on the ethernet interface ?
From: Olof-Joachim Frahm on 23 Mar 2010 00:52
Pascal Hambourg <boite-a-spam(a)plouf.fr.eu.org> writes: > Note that the definition of fec0::/10 as a site-local prefix has been > deprecated for years and is now reserved (cf. RFC 3879). If you do not > have an available global prefix, you can use a ULA prefix (Unique Local > Addresses, cf. RFC 4193) instead. A web-based ULA prefix generator is > available at <http://www.kame.net/~suz/gen-ula.html>. Yeah I noticed that, but it's not my network and I can't configure it, unfortunately, since I've got the necessary permissions only on one computer. > This is a basic prefix assignment mismatch. > Machine A thinks that the prefix is directly attached to the TUN > interface (diret route), but sends ICMPv6 Router Advertisement messages > telling that the prefix is directly attached to the ethernet link. > Because of these Router Advertisement messages machine B thinks that the > prefix is directly attached to the ethernet link, which is wrong. So > machine B sends ICMPv6 Neighbour Solicitation messages for addresses > within the prefix on the ethernet link instead of using the default > route defining machine A as the router, which would be the right thing > to do. > > My suggestion : > Define a different prefix for the ethernet link. > Have radvd advertise this prefix instead of the TUN prefix. No need to > advertise a route for the TUN prefix, the default route will handle it > just fine. Thanks so much for that explanation! It works, finally, and all packets go where they should :) >> on machine A, using tcpdump, no packets come through. > > Not even Neighbour Solicitation ICMPv6 messages on the ethernet > interface ? Yes they do: I forgot to supply the correct interface to tcpdump, therefore nothing was captured on that (ethernet) interface. Cheers, Olof -- The world is burning. Run. |