IPv6 inside Wireguard

[symon]

Hello,
I have a opnsense appliance inside my local network and since it has limited hardware I am just using it as a VPN endpoint. I opted for wireguard as VPN software. This is the network layout:

Code: [Select]

____________________________________________________________________
|                                                                   |
|                             |---------------- Internal Clients    |
|                             |                                     |
|                             |                                     |
------- ISP Router-------------------- OPNsense Box-----VPN Clients |                                                                 
|                             |                                     |
|                             |                                     |
|                             |----------------- DNS & Server       |
|                                                                   |
|____________________________________________________________________

The internal ISP IPv4-Subnet is 192.168.178.0/24  and the OPNsense VPN-net is 10.0.10.0/24.
The ISP-Router also gives out ULA (since I am running a DNS-Resolver for IPv6 and the given prefix from the ISP changes every few days). The IPv6-Net internally is fd00::/64. Also full IPv6-Adresses (2001: are given out to internal clients as well as a /60 prefix is delegated to the OPNSense Box.

The wanted scenario is: Roadwarriors should be able to connect via Wireguard, all traffic should be rerouted through VPN and the internal as well as external services should be reachable via both IPv4 and IPv6. The IPv4 part (OPNSense Box is doing a NAT) is working quite well already.

However I have problems with IPv6. I am really unexperienced with IPv6 so please correct me if I made wrong assumptions.
Since the prefix is rolling I decided it would be the best to give out ULA internally (so the DNS server is always reachable on a fixed address. So I gave the Wireguard-Endpoint the network fd01::/64. I also added an outbound NAT-Rule (see picture below). Also here are my configs for the clients:

Code: [Select]

interface: wg0
  public key: (hidden)
  private key: (hidden)
  listening port: 51820

peer: (hidden)
  endpoint: ip:55916
  allowed ips: 10.0.10.4/32
  latest handshake: 32 seconds ago
  transfer: 76.46 KiB received, 78.96 KiB sent

peer: (hidden)
  endpoint: ip:8886
  allowed ips: 10.0.10.2/32, fd01::10/128
  latest handshake: 1 minute, 55 seconds ago
  transfer: 235.91 KiB received, 2.03 MiB sent

peer: (hidden)
  endpoint: ip:34636
  allowed ips: 10.0.10.3/32, fd01::30/128
  latest handshake: 4 minutes, 51 seconds ago
  transfer: 213.72 KiB received, 1.31 MiB sent

However no IPv6 Access seems to be possible through the connection. The settings on the test-client (iPhone) are:

Code: [Select]

[Interface]
Address = 10.0.10.2/24, fd01::10/64
PrivateKey = [mobile.seckey]
DNS = 192.168.178.2, fd00::2

[Peer]
PublicKey = [vpn-server.pubkey]
PresharedKey = [vpn.psk]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = endpoint_domain:51820

Is there anything wrong with the setup? Or did I maybe mess something up with the network interface names or did I miss something? How is IPv4 working like charm, where IPv6 does not?

Maybe this helps debugging: I can see in the live-view, that the firewall lets packets from IPv6 NAT pass. Also (I am currently checking with https://ipv6-test.com ) the test says that "DNS6 + IP4" is working. Is it possible, that my NAT rule should be differentiating between internal and external addresses?

[chemlud]

ipv6 net not in "Allowed IPs" setting?

https://stanislas.blog/2019/01/how-to-setup-vpn-server-wireguard-nat-ipv6/

[symon]

Code: [Select]

peer: (hidden)
  endpoint: ip:8886
  allowed ips: 10.0.10.2/32, fd01::10/128
  latest handshake: 1 minute, 55 seconds ago
  transfer: 235.91 KiB received, 2.03 MiB sent

peer: (hidden)
  endpoint: ip:34636
  allowed ips: 10.0.10.3/32, fd01::30/128
  latest handshake: 4 minutes, 51 seconds ago
  transfer: 213.72 KiB received, 1.31 MiB sent

Both of these peers have IPv4 inside allowed IPs, they have "Address = 10.0.10.2/24, fd01::10/64" and "Address = 10.0.10.3/24, fd01::30/64" on the client side and are able to ping eachother.

I found the entry shown in the attached picture on the Rules Live View. The outbound NAT rule is set to translate IPv6 to "WAN Address". Anyways: WAN has two adresses. A publicly routable and an ULA. The Logs show that it is using the ULA for NAT (wich should afaik only be used for internal applications. Is it possible the ISP uplink box is blocking this as an invalid IP to communicate with global adresses?

[symon]

Okay I think I found at least one of the problem (I still do thing kere is some x-y-problem here).

As you can see in the alias table attached I created an alias for both IPv6 (GUA and ULA) addresses assigned to the WAN interface. I also changed the outbound-NAT to use the appropriate adress whenever possible. This actually does work.

Still the question remains: now IPs are hardcoded. That will probably make the whole construct unstable as the GUA is assigned via DHCPv6 and will change.
Is there any option to use the current adress (such as "Track Interface" within Interfaces)? Or is it even better to give GUAs from the assigned prefix to the VPN clients (and how, since the prefix will change as well)?

[Greelan]

Couple of suggestions for the outbound NAT rule. Suggest you don’t use the default “WireGuard net” but rather your own alias for your VPN networks (maybe your “Wireguard net” (lower case g) is an alias?). Also, try “Interface address” rather than “WAN address”

I assume you have firewall rules too allowing the VPN traffic

[symon]

Thanks for the suggestions. I changed the rules accordingly. It's still not possible to use "Interface address" within the IPv6 rules since it will pick the first one by default (it's the ULA) and since that is no GUA it cannot leave the local network.

[Greelan]

That’s interesting. Why do you give your WAN a ULA?

The favouring of the ULA over the GUA has also popped up in other contexts, eg diagnostics tools. Franco is looking at that, although I am not sure whether in the outbound NAT context

[Greelan]

Ah, I see your ISP router is handling the ULAs, not OPNsense

[symon]

Yep that is correct. It normally would not do this but (that's one of the reasons I thought I made a fundamental mistake here) I switched ULAs on because I have an internal DNS server. It's inside the ISP-Lan and has to be addressed somehow.

[Greelan]

You could just have your DNS server listening on IPv4. It will still be able to serve IPv6 records

[symon]

Nice thanks for the hint! I did not know that.

Unfortunately the ISP router decides to announce his own DNS server via DHCPv6 if I don't provide my own. So it seems like I have to use the IPv6 Address as well if I want DNS control.

The favouring of the ULA over the GUA has also popped up in other contexts, eg diagnostics tools. Franco is looking at that, although I am not sure whether in the outbound NAT context

Is there maybe a possibility to split the reveived IP-Adresses on the WAN-Interface to multiple virtual Interfaces? So that I could track an interface? Or maybe another option would be to use a delegated prefix from the ISP box inside the VPN Network so outbound traffic to GUAs will not have to be NATted?

[Greelan]

Your last idea might work

[Maurice]

IP addresses in WireGuard must always be configured statically, so if the prefix you get from your ISP changes regularly there is unfortunately no way to use GUAs in the tunnel.

ULAs work, but have severe limitations. Most clients prefer IPv4 if they don't have a GUA. So unless you make the tunnel IPv6-only or your road warriors need to connect to IPv6-only servers, IPv6 won't ever be used. Which also makes the IPv6 NAT kind of pointless: It won't see any traffic except for the occasional test.

[symon]

Sad to hear that. I'm still trying to figure out a way around this. I almost forgot there were limitations but I rebooted the OPNSense Box today and it got a new prefix. So things stopped working and it came back to my attention.
Is there a good reason, wireguard does not allow DHCP?

[chemlud]

Is there a good reason, wireguard does not allow DHCP?

What do you mean by that?

WG evaluates the target for the tunnel ONCE, when starting up (IP or resolving domain). Never again, before you restart it. I asked for this kind of functionality in the past (WAN with changeing lease from time to time or even worse: every night), but no idea if it's in the make. If you don't want to restart manually, a script testing the handshake and restarting might help?