WG Road-warrior IPv6 setup

[pawlisko]

The situation is quite simple.

OPNsense router is connected to Dynamic Dual-Stack ISP service.

LAN - IPv4 and IPv6 working, with the exception of ULA devices. Probably same issue like with WG.

WG
IPv4 setup is working. I can connect using IPv4, go to the Internet, go to LAN, etc. It is how it should be.

IPv6 - I have problems with it. I can connect to the router via IPv6, but then nothing.
I am using ULA in my config as my IPv6 address may change, and WG setup should not - I don't want to redo the setup every time my IPv6 changes.
I don't have any traffic going to the Internet via IPv6. I assume there are some additional firewall rules I should put in. Also NPTv6 will be great even if I have to change it manually - I know there is development on this.

So - how to enable ULA traffic within Interface?

[tiermutter]

It´s quite the same as for IPv4:
- Set ULA tunnel address for VPN server
- Set ULA endpoint IPs from range specified as tunnell address
- Set FW rule on WG interface allowing traffic from the specific range

Would be easier if you provide your WG config (without keys).

[pawlisko]

Part 1 of 2 of my setup

[pawlisko]

Part 2 of 2 of my setup

[Greelan]

Did you follow the wiki? https://wiki.opnsense.org/manual/how-tos/wireguard-client.html

You will need an outbound NAT rule - see step 5(b)

[pawlisko]

You will need an outbound NAT rule - see step 5(b)

Already in

Please see: NAT-1-setup.png

[Greelan]

Not quite. Check the Interface and Source Address

[pawlisko]

NAT-2-setup.png

Also in

[Greelan]

Right. So what is NAT-1 supposed to achieve? Or the NPT6 rule for that matter? I suggest getting rid of extraneous stuff which is possibly getting in the way

[pawlisko]

OK,

I will delete all FW rules and start with User Guide to have it working. But my overall goal is to have each of my WG clients to use their own IPv6 GUA based on their ULA - hence NPTv6. And that is not part of User Guide.

Would you be so kind and provide some steps how to achieve that?

[Patrick M. Hausen]

So - how to enable ULA traffic within Interface?

Frequently it's not the network device, router, firewall, ... but the end devices themselves. IMHO - and there is to my knowledge nothing in the standard that says otherwise - ULA should be treated like RFC1918 for IPv4. Allowing for a stable local prefix and possibly NAT.

But ...

Unfortunately the common interpretation of the "happy eyeballs" algorithm - defining the priority of the protocols in a dual-stack scenario - has rendered ULA essentially useless.

Because the order is:

• IPv6 GUA
• IPv4
• IPv6 ULA

Obvious that this doesn't work as desired? E.g. an Apple device will consider no IPv6 connectivity at all if it has only ULA addresses.

I refer you to the brilliant, sarcastic, entertaining, incredibly knowledgable Ivan Pepelnjak for further reading:
https://blog.ipspace.net/2022/05/ipv6-ula-made-useless.html

What I do in situations where I - rarely, but still - want a fixed internal prefix and NAT for IPv6, is that I borrow IPv6 addresses from other installations under my control. For my German Telekom DSL line I get a fixed /56. I use two /64 out of that for two cloud instances I run at Vultr. Since I NAT anyway, everything is working as expected and the use of "my" (DTAG, really) addresses guarantees there will be no conflict.

If you are working in an enterprise context consider getting a fixed GUA IPv6 assignment and use parts of that for private infrastructure.

HTH,
Patrick

[pawlisko]

So I read this article, I read RFC, but life is life.

So let me tell you a crazy story - I work for Big4 Bank (does not matter which one). I work using VDI, as a part of security systems no connections are allowed to F5 gateway from IPs that belongs to any VPN service (Global Security team is really proactive and bans all VPN networks and IPs all the time). Having said that - I need to connect from IP belonging to my ISP. I am based in the US. My ISP leases me /56 prefix but it is dynamic, I can try to prevent the release of IPv6 prefix, but it is not guaranteed. So I have to use ULA for my WG setup. This is the situation.
I do travel internationally, maybe not as I used to do it but I do. My company is not so keen about me traveling, especially that I am in a "low band" (Band 0 is CEO, I am at 5), but due to certain skills I have, my management allows me to travel at multiple conditions (travel registered with US Department of State portal, multiple ways to communicate with me, they have to know all the addresses I stay, I need to register myself additionally with the local US embassy etc, but I have to appear to the rest of the company (including dreaded Global Security) as I would be at home in the US. Please don't ask about getting official approval as this is even more complicated and legal must be involved, and if I am traveling to any country which borders any of the "hot" zones I am not allowed, also working from abroad, even thou I can work officially from multiple countries (I hold more than 1 citizenship) may create a taxable events where my company and I would be liable for paying local taxes, etc. I did that once (going official route) and since that time there is this "understanding". This is the setup of the story.
Now the life - I've been to places where I had only IPv4 connectivity - no problem for my work; I was in places where there was Dual-Stack, also no problem; but also I've been in places where the network was only IPv6 and ISP handled IPv4 traffic via NAT64 (in US i.e. T-Mobile US is doing that) - and without the ability to establish IPv6 tunnel to my home there was no way of working. Therefore I have to have a fully working dual-stack WG server at home. If you add dynamic prefix allocation ULA is the only way to setup WG tunnel, and then just NPTv6 out. NAT does not work as sometimes I have to establish few different connections to different VDIs (laptop and iPad) and same IPv6 address gets Global Security to act. That is why I need my setup.

I am new to OPNsense - I had my setup working quite OK with MikroTik, but their rigid stance on IPv6 ULA and NPTv6 development, even though I had run a workaround, pushed me here. I put some scripts together to update to the new prefix but the idea was for each tunnel:
/ipv6 firewall nat add action=src-nat chain=srcnat src-address=ULA#1/128 to-address=GUA#1/128
/ipv6 firewall nat add action=dst-nat chain=dstnat dst-address=GUA#1/128 to-address=ULA#1/128
When IPv6 prefix changed script was updating GUA in both chains making this worked like magic.

I know that with 22.8 (sometime in January as per roadmap) NPTv6 should be operational with tracking interface so hopefully it will be working somehow.

And last thing - Apple on DualStack with ULA works with IPv6 great. The only thing to be aware is addressing should start with fd00:: not with fc00::
Also I have few devices in my local network which are not DHCP enabled for obvious reasons (like CISCO Wireless Lan Controller, few core managed switches) so I have to have ULA working on LAN interface as well - and I achieved that using Virtual IPs so it started to work on LAN with NPTv6 - still I have to update if prefix changes but...

[Patrick M. Hausen]

If you are going to NPT6 anyway, why not borrow a GUA /64 from "somewhere"? Register with Hurricane Electric for a tunnel and use what you get from them. Nobody will ever see the "borrowed" addresses, you only need to take care they never overlap with anything on the public Internet you need to reach.

That's BTW why we use 217.29.44.0/24 - 217.29.46.0/24 for internal networks with NAT. For one we can - RIPE member and this is our address space. Second and the reason why: no conflicts with customers using RFC1918 when setting up VPNs. Works like a charm.

I can give you a /64 of mine  There will never be a public service you need to reach on that network.

[pawlisko]

so how to change config to include NPTv6 in WG deployment?

[Patrick M. Hausen]

You put an NPT6 NAT rule on your WAN interface.