2

I (can) have a bunch of IPv6 addresses on a (virtualized) server in the internet from my hosting provider assigned in the network which is directly attached (from /64 where eth0 is configured). How I can use some if these IPv6 addresses for my VPN (wireguard) to that server?

Usual there must be a route to the IPv6 addresses used inside the VPN which points to my server, but there is no such routing entry and therefore the neighbor discovery solicitation won't work. Can I define the IPv6 addresses which are used for VPN also as virtual addresses on the primary interface (eth0) to answer to neighbor discovery? For IPv4 I use NAT without problems, but using NAT with IPv6 is not a solution, isn't?

2
  • basically you want your home computer to appear to be on the same network as your server, when you access the internet? Apr 17, 2023 at 14:47
  • if such a setup is possible with wireguard, this can also be an option for me
    – Micha
    Apr 17, 2023 at 14:53

1 Answer 1

1

Assuming the system was configured as a router as usual, for example with a /128 route to each individual IPv6 address through the tunnel (with the help of wg-quick if needed). I can't help on this part because no information was provided in OP.

Now, because the upstream router (the server's router reachable on eth0) doesn't have a setting to know that it must route such addresses specifically through the server and its configuration can't be changed, it will search for the target in the LAN using NDP, but the server, routing but not owning this address, will not care for this query even if received: no connectivity.


One can configure the server to reply for such addresses without actually owning them: act as a proxy and reply when receiving such requests via NDP, hence it's called ND proxy. In the end the router will know from (dynamically resolved) NDP where to send traffic to such address instead of knowing it through (static) routing setup. Once in place on the server this is all handled by the Linux kernel.

Both settings below must be done (this might slightly differ from Linux' arp_proxy IPv4 equivalent setup).

  1. enable proxy_ndp on the interface where ND proxy has to be done (eth0):

    sysctl -w net.ipv6.conf.eth0.proxy_ndp=1
    

    Has to be done once.

  2. For each IPv6 address that will be routed by server add a ND proxy entry. For example with 2001:db8:1:2::4242 that would be:

    ip neigh add proxy 2001:db8:1:2::4242 dev eth0
    

    For the little details, one can also check the server joined a multicast address (used for NDP) related to the proxy address. Eg:

    $ ip maddr show dev eth0 | grep '42:*42 *$'
            link  33:33:ff:00:42:42
            inet6 ff02::1:ff00:4242
    

    The keyword proxy is mandatory to handle such addresses (-6 should also be used all the time or at least when there's no context telling it's about IPv6 NDP and not IPv4 ARP). Examples:

    ip -6 neigh show proxy # display ND proxy entries configured whatever the interface
    ip neigh delete proxy 2001:db8:1:2::4242 dev eth0 # delete a single entry
    ip -6 neigh flush proxy all dev eth0 # delete all of them on eth0
    

    Still, they are probably quite frail and would disappear automatically for example when the interface is set down then up: this setup should be added in the network tool configuring eth0.


Note: there's no other way with the kernel than to provision each address individually with ip neigh ... proxy .... In case a whole LAN or subnet has to be handled in such a way, one can instead set the interface in ALLMULTI so it won't drop such traffic and then handle this via userland. A tool already does this job: ndppd. Using this tool is not recommended for OP's case.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .