Is my WAN IPv6 different from my /48 fixed prefix?

Started by JamesFrisch, December 03, 2024, 07:53:35 AM

Previous topic - Next topic
December 03, 2024, 07:53:35 AM Last Edit: December 03, 2024, 07:55:20 AM by JamesFrisch
Hi guys


Probably stupid question but I could not find an answer online.
Is it possible that my WAN IPv6 is in a different subnet than my static /48 prefix?


I currently have IPv4 WireGuard on OPNsense. Now I want to make my WG dual stack.
I get the static IPv6 /48 prefix of lets say 1234:1234:1234::/48
Because of that, my VLANs use
1234:1234:1234:10::/64
1234:1234:1234:20::/64
and so on with track interface.

When I go to the interfaces overview, I see that it used the some (I think random) MAC for all VLAN.
1234:1234:1234:10:4444:4444:4444:4444/64
1234:1234:1234:20:4444:4444:4444:4444/64

also each interface gets a link local fe80::4444:4444:4444:4444/64



This far I can follow. What irritates me me is the WAN interface.

1234:1234:2222:29:4444:4444:4444:4448/64
1234:1234:2222:29::1f/128
fe80::4444:4444:4444:4448/64

The ending with "8" I can understand. This is because the WAN NIC has a slightly different MAC from the LAN NIC.

What I don't understand is the 2222:29. Since I have the static prefix 1234:1234:1234::/48 assigned, is it possible that for my WAN I get two IPv6 that are not in this subnet?

Is there any documentation about the differences between these two IPv6?
First one does not seam to be a privacy extended IPv6, so why even have two?






fe80 are link local addresses https://en.wikipedia.org/wiki/Link-local_address

IPv6 hosts can have many IP addresses. After all, saying that there are plenty available is an understatement. Many hosts do pick a random one for privacy. The servers they connect to won't then be able to track them by their client IP (they dump a wheelbarrow of cookies on you instead).

The WAN side can be completely different again. Your ISP will route your delegation to the internet and back. No guarantees that any of the hops along the way will be addresses you recognise. My WAN interface only has an fe80 address, and yet the little guy dances for me at https://www.kame.net/

Bart...

December 03, 2024, 09:55:59 AM #2 Last Edit: December 03, 2024, 10:03:39 AM by JamesFrisch
Hi Bart.

Thanks you for your input, but that does not really answer any question and only repeats what I already stated.
English is not my native language, maybe there is a language barrier on my end.
I will try to phrase it differently.


I have a NGINX webserver running in VLAN 50.
I can reach that webserver by NATing my WAN IPv4 1.1.1.1 to a local IPv4 10.0.50.2.
I can also reach that webserver by IPv6 1234:1234:1234:50::2 (which is part of my static 1234:1234:1234/48 prefix, VLAN 50 interface has the setting track interface with 50, so I get a 1234:1234:1234::50/64 subnet)

That makes my NGINX webserver dual stack.
Now I would like the achieve the same for my WireGuard instance on OPNsense.
The IPv4 part is easy and working.
But I struggle with the IPv6.
How can I achieve dualstack WG for OPNsense?

It's normal for your WAN interface to get an IPv6 address outside your delegated prefix. The delegated prefix is inteded for your router (firewall) to use for internal networks behind it. Is the /128 address on your WAN interface not static too? If it's not, you could use the address of one of your other interfaces as the destination for WG instead. The /128 on your WAN interface is probably from DHCPv6, and the /64 one from SLAAC, I'd guess....

December 03, 2024, 11:53:36 AM #4 Last Edit: December 03, 2024, 11:59:46 AM by meyergru
Yes, the WAN IPv6 is usually from another IPv6 range than your delegated prefix.

That is because with DHCPv6, you will usually get a /128 IA_NA for your WAN and a /56 (or /48) IA_PD for prefix delegation.

This may pose some problems for dynamic DNS, because when your OpnSense makes a request, it goes through the WAN interface, whereas your LAN clients will even have another prefix, such that masking the EUI-64 will not suffice.

However, since a few versions, OpnSense has the ability to use one of your IA_PD prefixes for the WAN instead of the IA_NA address. Just set "Request prefix only", and use some "Optional prefix ID" that is different from all of your "track interface" prefixes. This way, your WAN and LAN prefixes will be the same for your delegated prefix size (i.e. less than the first 64 bits).

Another alternative is to just use "request prefix only" and leave the WAN interface completely without any IPv6 assigned. In that case, one of the LAN interface IPv6 addresses will be used for outbound connections instead.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 440 up, Bufferbloat A+

QuoteIt's normal for your WAN interface to get an IPv6 address outside your delegated prefix.

Cheers for that.


QuoteIs the /128 address on your WAN interface not static too?
Don't know to be honest, I have to ask my ISP.
It is DHCPv6.


QuoteIf it's not, you could use the address of one of your other interfaces as the destination for WG instead.
Interesting. So I could use any interface IPv6? Probably then have to adjust the "Allow all UDP on Port 51820 to WAN address" rule, since the destination isn't WAN address anymore. Since I wg Interfaces are not allowed to have IP settings, I probably need to create a fake Interface which is ok, but not very sleek in my opinion.


QuoteThe /128 on your WAN interface is probably from DHCPv6, and the /64 one from SLAAC, I'd guess....
That was my guess too.
Do you think both are publicly routable?
I tried both of them, but was not able to establish a connection. Maybe some other config error on my part.


Quote
Yes, the WAN IPv6 is usually from another IPv6 range than your delegated prefix.

That is because with DHCPv6, you will usually get a /128 IA_NA for your WAN and a /56 (or /48) IA_PD for prefix delegation.

Cheers!

QuoteThis may pose some problems for dynamic DNS, because when your OpnSense makes a request, it goes through the WAN interface, whereas your LAN clients will even have another prefix, such that masking the EUI-64 will not suffice.

I don't understand that part to be honest  :)


QuoteHowever, since a few versions, OpnSense has the ability to use one of your IA_PD prefixes for the WAN instead of the IA_NA address. Just set "Request prefix only", and use some "Optional prefix ID" that is different from all of your "track interface" prefixes. This way, your WAN and LAN prefixes will be the same for your delegated prefix size (i.e. less than the first 64 bits).


Another alternative is to just use "request prefix only" and leave the WAN interface completely without any IPv6 assigned. In that case, one of the LAN interface IPv6 addresses will be used for outbound connections instead.

Sounds good! I trying to make sense of these options and to understand the implications.
The second option seems like the sleeker way to do it. I don't need a SLAAC nor a DHCPv6 IPv6 on my WAN interface. To only real downside I can see, is that maybe then OPNsense itself is not IPv6 ready anymore and can only check for updates over IPv4?

Quote from: JamesFrisch on December 03, 2024, 01:47:19 PM
Interesting. So I could use any interface IPv6? Probably then have to adjust the "Allow all UDP on Port 51820 to WAN address" rule, since the destination isn't WAN address anymore. Since I wg Interfaces are not allowed to have IP settings, I probably need to create a fake Interface which is ok, but not very sleek in my opinion.

The incoming interface would still be WAN. The destination address could be "This Firewall", which could cover any routable address.


Quote
QuoteThe /128 on your WAN interface is probably from DHCPv6, and the /64 one from SLAAC, I'd guess....
That was my guess too.
Do you think both are publicly routable?
I tried both of them, but was not able to establish a connection. Maybe some other config error on my part.

Assuming they're from a routable prefix, I would expect so. Maybe try to get ping working before WG? https://tools.keycdn.com/ipv6-ping can be quite handy....


Quote from: JamesFrisch on December 03, 2024, 01:47:19 PM
QuoteThis may pose some problems for dynamic DNS, because when your OpnSense makes a request, it goes through the WAN interface, whereas your LAN clients will even have another prefix, such that masking the EUI-64 will not suffice.

I don't understand that part to be honest  :)

If your IPv6 ranges are not static, you will have to use dynamic DNS. To update that with your current IPv6, you usually use a cnetralised approach, in that OpnSense updates the DNS name to its IP. While that works fine with IPv4 behind NAT (because all devices use the same IP), it does not with IPv6, because all devices have different IPv6s. They share a common prefix, however, so you can strip off the lower (EUI-64) part from the sender IP and attach the EUI-64 to that.

However, that obviously does not work if even the prefix is different, as is the case with IA_NA and IA_PD. Therefore, it is best NEVER to to the IA_NA in such cases.

Quote from: JamesFrisch on December 03, 2024, 01:47:19 PM
Sounds good! I trying to make sense of these options and to understand the implications.
The second option seems like the sleeker way to do it. I don't need a SLAAC nor a DHCPv6 IPv6 on my WAN interface. To only real downside I can see, is that maybe then OPNsense itself is not IPv6 ready anymore and can only check for updates over IPv4?

No, as I said, it uses one of its LAN IPv6 addresses for outbound connections.
Intel N100, 4 x I226-V, 16 GByte, 256 GByte NVME, ZTE F6005

1100 down / 440 up, Bufferbloat A+

December 03, 2024, 05:15:08 PM #8 Last Edit: December 03, 2024, 05:18:38 PM by JamesFrisch
Quote
The incoming interface would still be WAN. The destination address could be "This Firewall", which could cover any routable address.

Right

QuoteAssuming they're from a routable prefix, I would expect so. Maybe try to get ping working before WG? https://tools.keycdn.com/ipv6-ping can be quite handy....

Good idea. I can ping both IPv6 and all my Interface IPv6s.


QuoteIf your IPv6 ranges are not static, you will have to use dynamic DNS.
I don't know if these two IPv6 are static, but I do know that the prefix is static.


QuoteTo update that with your current IPv6, you usually use a cnetralised approach, in that OpnSense updates the DNS name to its IP. While that works fine with IPv4 behind NAT (because all devices use the same IP), it does not with IPv6, because all devices have different IPv6s.
I will probably create a seperate subdomain like wg.mydomain.com.
The IPv4 isn't static, but gets updated by DynDNS.
The IPv6 is prefix and thous at least the interfaces are static, so I will manually add them.
Since it looks comes in through WAN, I think it does not really matter what interface the IPv6 is coming from?


My guess is that WG then will depending on the network decide if it connects over IPv6 or IPv4.


Unfortunately I can't test it right now, because iPhone Hotspots are IPv4 only. Yeah, no kidding, even if the phone itself has has IPv6 cellular support, hotspot will be IPv4 only :)


I gave it another try today, but I am still pretty lost  :'(

I can connect to mydomain.com over IPv4, no problem.
I see the client in the Status page and I can open up a local IPv4 webpage.

I created ipv6.mydomain.com with only a AAAA record.
But neither then interface WAN IP, nor one of the VLAN subnets interface IPv6 works.

The Firewall rule for LAN is set to both. I even changed the WAN rule from "Destination WAN Address" to "Destination any" just to be sure. Still no luck. I can ping the IPv6.

What happens when you try? Do you get a handshake?

Is your WAN rule configured for protocol IPv4+IPv6? It's working for me, but I'm using "This Firewall" as the destination in my WAN rule.....

Nothing, no handshake.

WAN is for IPv4 and IPv6. And even "Any" instead of "This Firewall".

What I don't have is allowed IPv6 IPs for the client, but I don't think that is needed, right?
I can have an IPv6 only Tunnel that only routes IPv4 traffic?

Yes, the peer endpoint can be IPv6 but only IPv4 networks allowed through the tunnel - that's basically how mine is. I just added the v6 peer tonight to see if I could get it to work. It worked first try. Are you sure v6 is working on your client device?

That is good to know, thanks.
Since I can open up ipv6.google.com, I think so, yes.

Try a packet capture on your WAN interface for port 51820 when you're attempting to connect....