IPv6, TUN, routing

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.

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 ?

Pascal Hambourg <boite-a-(E-Mail Removed)> 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.