ipv6 wireguard Nat help

Started by Dmonroe, August 03, 2022, 06:09:12 PM

Previous topic - Next topic
Hello, I'm trying to convert as much of my network as I can to ipv6-only. Right now I'm trying to convert my wireguard server to use ipv6 addresses, and I've run into a problem. I get my prefix via DHCPv6 from my ISP, so they can change it at any time, and my clients connect to the server using dynamic dns. Wireguard, however, requires that the clients have static addresses, which makes sense, because the server would have no way to tell the client it's new address when it's trying to establish a connection. The way around this, and also how wireguard works with ipv4, is to have a static internal network and use NAT to connect to the internet, which is what I'm trying to set up with wireguard using ipv6. However, it seems that ipv6 NAT does not currently work. I can successfully ping machines on my LAN over ipv6 from a wireguard client, and I can sucessfully ping ipv4-only internet hosts via tayga, but when I try to ping ipv6 hosts on the internet it doesn't go through. Googling found this: https://forum.opnsense.org/index.php?topic=13896.0 from 2019 which seems to be the same problem and has no resolution. Is there any way to get this working, or am I stuck using ipv4 for wireguard? Attached is a screenshot of my outbound NAT settings.
Thanks in advance.

In general, IPv6 outbound NAT works with DHCPv6 WANs. Quite a few people use this. If the behaviour mentioned in the 2019 thread actually was a bug, it probably has been fixed at some point. There was a bug in 22.7, but that has been fixed in 22.7_4: https://github.com/opnsense/changelog/blob/master/community/22.7/22.7#L142

Your issue might be specific to WireGuard or your config. Can you post your wg tunnel address and allowed IPs?

Cheers
Maurice
OPNsense virtual machine images
OPNsense aarch64 firmware repository

Commercial support & engineering available. PM for details (en / de).

Sorry to say this but it still problems with IPV6 not fixed with the patch
And i revert to 22.1 and have take a closer  look at the IPV6 and the problem is the same
the only different is that it dont pop up at the console it got blocked in firewall instead
this applies only my mobile phones all servers and pc works fine

//Peter
Stay safe
Peter

I'd suggest ULAs configured for the tunnel and otherwise set up in accordance with the how-to (https://docs.opnsense.org/manual/how-tos/wireguard-client.html) should achieve what you want. NAT for the ULAs should work fine

August 04, 2022, 11:54:12 AM #4 Last Edit: August 04, 2022, 11:59:48 AM by YipieKaie
Thx Greelan

I know know what cause this problem.
Mobile phones need to talk (Stateless DHCPv6 and SLAAC (O+A flags).
I use Managed (Stateful DHCPv6 (M+O flags)

DHCPv6-Prefix Delegation. It result in each client receiving a Link Local from a
DHCPv6 server rather than a single IP address

If i use Stateless it works fine and it then use multiple addresses from its prefix
So there is nothing wrong with OPNsense its my configuration that i use since i have
Static IPV4/IPV6 addresses on my internal network, and i also have a static IPV4/IPV6 address
from my ISP.

//Peter
Stay safe
Peter

Quote from: Maurice on August 04, 2022, 01:53:59 AM
In general, IPv6 outbound NAT works with DHCPv6 WANs. Quite a few people use this. If the behaviour mentioned in the 2019 thread actually was a bug, it probably has been fixed at some point. There was a bug in 22.7, but that has been fixed in 22.7_4: https://github.com/opnsense/changelog/blob/master/community/22.7/22.7#L142

Your issue might be specific to WireGuard or your config. Can you post your wg tunnel address and allowed IPs?

Cheers
Maurice

Hello, sorry it took so long to get back to you, life happened pretty much immediately after I posted this. I'm attaching screenshots my wireguard server, client, and firewall settings over a couple posts, and the client successfully connects to the server so I don't think that can be the problem? The firewall has a bunch of adblocking rules that I've disabled to make sure they weren't the problem, the only current rule is the allow everything one. Thanks in advance.


You need to give OPNsense an actual address in the local config - eg {prefix}::1/64 (substituting your actual prefix ofc)

At the moment you've only specified a subnet with no address

Also not sure whether OPNsense has issues parsing IPv6 address notation that hasn't been shortened in accordance with the RFC. So suggest doing that too on the endpoint IPs (collapsing the 0000s etc)

@Dmonroe, no worries, life is always more important! :)

fda6:4040:2c9a:d657::/64 actually is a valid IPv6 address, although a special one. The lowest address in an IPv6 subnet is the subnet router anycast address. I wouldn't use that here either, so as @Greelan suggested, better use fda6:4040:2c9a:d657::1/64 or something like this.

No idea whether this is the root cause of the NAT issue. If it isn't, you might want to try manually entering the source network for the outbound NAT rule. Also, does your WAN interface have a GUA?

Cheers
Maurice
OPNsense virtual machine images
OPNsense aarch64 firmware repository

Commercial support & engineering available. PM for details (en / de).

Quote from: Maurice on August 08, 2022, 12:07:54 AM
@Dmonroe, no worries, life is always more important! :)

fda6:4040:2c9a:d657::/64 actually is a valid IPv6 address, although a special one. The lowest address in an IPv6 subnet is the subnet router anycast address. I wouldn't use that here either, so as @Greelan suggested, better use fda6:4040:2c9a:d657::1/64 or something like this.

No idea whether this is the root cause of the NAT issue. If it isn't, you might want to try manually entering the source network for the outbound NAT rule. Also, does your WAN interface have a GUA?

Cheers
Maurice

Thanks, for the advice, I've changed the tunnel address so it ends in ::1 and changed the NAT rule to specify the wireguard network specifically, and the issue persists. I don't know how to tell if my wan has a GUA, so I've attached screenshots of the new NAT config and my WAN interface from the overview section.

The WAN interface is the issue. As you can see, it doesn't have an IPv6 address. So the NAT rule has no address which it could use as a translation target.

Did you by any chance enable "Request only an IPv6 prefix" in the WAN interface settings?
OPNsense virtual machine images
OPNsense aarch64 firmware repository

Commercial support & engineering available. PM for details (en / de).

Quote from: Maurice on August 08, 2022, 01:26:25 AM
The WAN interface is the issue. As you can see, it doesn't have an IPv6 address. So the NAT rule has no address which it could use as a translation target.

Did you by any chance enable "Request only an IPv6 prefix" in the WAN interface settings?

Yes! Because the instructions I followed ( https://forum.netgate.com/topic/155534/verizon-fios-and-ipv6-which-settings-work/2?lang=en-US ) told me to. incidentally, I just tried unchecking that option and my router failed to get any ipv6 at all from Verizon.

Ah okay, then your ISP leaves the WAN interface unnumbered. Not a very common configuration, but not unheard of.

As a workaround, try switching 'Translation / target' in your NAT rule to 'LAN address'. 'Interface' needs to remain 'WAN'.
OPNsense virtual machine images
OPNsense aarch64 firmware repository

Commercial support & engineering available. PM for details (en / de).

Quote from: Maurice on August 08, 2022, 01:55:23 AM
Ah okay, then your ISP leaves the WAN interface unnumbered. Not a very common configuration, but not unheard of.

As a workaround, try switching 'Translation / target' in your NAT rule to 'LAN address'. 'Interface' needs to remain 'WAN'.

It works! thank you so much! i would never in a million years have managed to figure that out on my own.

Glad it works. The translation target is probably the only setting you actually had to change, but hindsight is always 20/20... ;D

Cheers
Maurice
OPNsense virtual machine images
OPNsense aarch64 firmware repository

Commercial support & engineering available. PM for details (en / de).