OK, I've sorted out my network issues server but it turns out that I
was misinterpreting the tcpdump output on my VPS. When an external
computer tries to ping my client's virtual IP address, the VPS's
gateway router is *not* forwarding the pings to my server where they
can be shoved into the IPsec tunnel to the client. So it looks like
the iked responder needs to send IPv6 neighbor advertisements for the
allocated address after all. Is there a way to do this?
I have tried two things so far:
1. Manually assign the [randomly allocated] IP address to the
responder's physical network interface so it knows it has ownership
of that address:
# ifconfig vio0 inet6 alias 2001:db8:2::1234:5678
Of course, this breaks the tunnel. When the responder sees packets with
destination 2001:db8:2::1234:5678 it consumes them locally instead of
routing them down the IPsec tunnel.
2. Advertise ownership of the address with rad:
$ cat /etc/rad.conf
interface vio0 {
prefix 2001:db8:2::1234:5678/128 {
autonomous address-configuration no
}
}
This doesn't work either because a router advertisement is not the same
as a neighbor advertisement. But I tried!
A third option would be to use a layer 2 tunnel so that the client
would be responsible for sending its own neighbor advertisements. But
the cost is high: I need to configure a gif(4) interface on the client
and now I'm pushing big fat Ethernet frames across the tunnel instead
of modestly portly IPv6 packets. Worse, if I want non-OpenBSD clients
to connect to the server, I have to figure out how to set up the client
side of a layer 2 tunnel on whatever OS they're using. So much work
just to get a globally-routable IP address!
Here is my vision of a perfect world. It's common for IPv6 nodes to
request a new random IPv6 address every couple of hours; OpenBSD's
inet6 autoconf does this by default. There is no shortage of IPv6
addresses on a LAN, and the process of requesting new ones is pretty
well standardized . So what would be fantastic is if instead of
putting "config address 2001:db8:2::/64" in the responder's iked.conf,
I could put "config inet6 autoconf vio0" instead. Then iked would
make sure that vio0 is using autoconf addresses and, if so, it would
request a new address via SLAAC (preferably randomizing all 64 bits
instead of just the bottom 32 bits like it does right now), assign
that address to the client, configure all the routing, and then would
somehow configure vio0 to claim ownership of that address for
NDP neighbor solicitation purposes, but have the kernel *not* claim
the address for routing purposes. The client config wouldn't change
at all; it would still say "request address any". But since we're
visualizing a perfect world and not just a great world, there would
also be an optional "temporary" flag which causes the client to
request a new address every couple of hours (just like how inet6
autconf does on regular interfaces)---since one of the intended use
cases for this would be concealing your region of origin, it seems
like privacy features should be easy to request.
But since I'm not [currently] offering to figure out how to implement
this myself I'll make do with what I have. Is there a way to make the
the responder/server send neighbor advertisements for the address it
allocated for the client, so that this address will be usable on the
global Internet?
Thanks,
Anthony
