On 2023-07-05, Anthony Coulter <b...@anthonycoulter.name> wrote: > 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?
Your simplest options are either to ask upstream to route traffic to you for the whole subnet (this will probably involve adding a new subnet and routing it via the existing address), or NAT traffic so it comes from the address the upstream router is expecting. > 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. What you're actually trying to do here is respond to NDP requests as a proxy. It's not a clean way to do it (the clean way is "upstream routes you a subnet"), but some people are trying to do this on cheap services that are only intended for a single host connection and that's about the only way. In this case you might be able to do it with ndp -s, as the "proxied" address is down a tunnel and not going to respond to NDP itself anyway, so it doesn't hit the main problem for arp/ndp proxy in OpenBSD which is that it answers on all interfaces, you can't tie it to one in particular. (For some other use cases, where you're on a /64 behind an ISP router, and have other hosts on a different ethernet interface, it looks like https://github.com/toru-mano/nd-reflector might do the trick). > 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 . On a LAN, yes there's a common way to do it. Not so much over a tunnel though. > 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". autoconf privacy addresses require that old addresses stay active so that long-running connections don't die. You're asking hell of a lot from a number of different subsystems, some of which do not have a way to handle this, to make it all work. -- Please keep replies on the mailing list.
