First post - please be gentle :)
Background
My ISP is Community Fibre (London). The IPv4 bit is CGNAT and working, and I believe I only get a /64 IPv6 subnet (neither ideal).
Using my old Draytek router, I am able to use SLAAC without DHCPv6 and my Windows and Mac clients successfully get/generate an IPv6 address and a temporary IPv6 address as well as an fe80 link local. The only issue is that the Draytek can't route IPv6 packets quick enough - I only get 300Mbs on a 1Gbs connection (it's fine on IPv4 which is hardware accelerated). Hence I built an OPNsense box.
All is good on OPNsense IPv4, and I can make IPv6 work too, but I only get one public IPv6 address per client – no temporary one. DHCPv6 is running and seems to be required for this to happen – if I disable the service there are no Ipv6 addresses received via SLAAC. Therefore, I suspect the issue is to do with SLAAC, DHCPv6 and prefixes but I can't work it out.
The Question
I would like to get IPv6 working in the same way as my Draytek, but faster! I.e. Using SLAAC so that Windows and other clients can create two public addresses – one main one and one temporary. Ideally without DHCPv6, but that would be the icing on the cake.
Is this possible?
My setup
I currently have a WAN interface and a single Bridged LAN interface (3 ports working well). With the following settings I get a single working IPv6 address (plus IPv4 of course)
Interfaces>WAN:
Block private networks – checked
Block bogon networks – checked
IPv4 Configuration Type – DHCP
IPv6 Configuration Type – DHCPv6
MAC address – Spoofing the one my ISP likes
DHCPv6 client configuration:
Basic
Request only an IPv6 prefix – checked
Prefix delegation size - 64
Send IPv6 prefix hint – checked
Interfaces>LanBridge
Block private networks – unchecked
Block bogon networks – unchecked
IPv4 Configuration Type – Static IPv4
IPv6 Configuration Type – Track Interface
Track IPv6 Interface:
IPv6 Interface - WAN
IPv6 Prefix ID – 0x0
Manual configuration – unckecked
(I have previously checked this and tried lots of things. Even after disabling it, the router advertisement config isn't always cleared – is that a bug?. I end up restoring a backup config)
I have played around with this for hours, so any guidance really appreciated (https://forum.opnsense.org/index.php?topic=27288.msg149991#msg149991 and https://forum.opnsense.org/index.php?topic=36986.0 looked useful, but to no avail)
Thanks in advance.
If you want to use SLAAC without DHCPv6, check "Manual configuration" in the track interface settings. Then disable the DHCPv6 server and set Router Advertisements to "Unmanaged".
Cheers
Maurice
Apart from a draft that suggest using of variable-length SLAAC (https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/), any current RFC pertaining to IPv6 makes an assumption of a length of 64 bits for the interface identifier. For SLAAC, the managed interface identifier is then the EUI-64 that is derviced from the MAC.
Thus, it should be possible to have a /64 prefix delegation size, but in that case, only one local interface can take that prefix, such that the other local interfaces cannot have IPv6 GUAs.
It seems you configured that already like that. When you look at /var/etc/radvd.conf, it should look something like:
# Generated RADVD config for manual assignment on lan
interface br0 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1500;
AdvDefaultPreference medium;
AdvManagedFlag on;
AdvOtherConfigFlag on;
prefix 200x:xxx:xxx:xxxx::/64 {
DeprecatePrefix on;
AdvOnLink on;
AdvAutonomous on;
};
RDNSS 200x:xxx:xxx:xxxx::/64:f690:eabb:fe00:7489 {
};
DNSSL lan {
};
};
Essentially, it would not look any different even with a /56 prefix delegation length, you could just have more than one interface section. You can check if the content is O.K. and if RADVD is running. Also, the LAN interface should have an IPv6 GUA.
BTW: With "request IPv6 prefix only", your WAN interface should not have a GUA IPv6, either.
P.S.: With your LAN bridge, all of the needed tuneables are set, I guess?
Thanks for the replies both.
Maurice, yes I tried this as per the link above, so I am assuming I have got something else wrong.
Meyergru, I'll check and report back. I'm still on the nursery slopes with IPv6 so this is a good learning exercise. It will be interesting to see what address the LAN interface has. From what I have read the WAN interface should be happy with an fe80 address.
More soon
So this morning I have 'turned on 'Allow manual adjustment of DHCPv6 and Router Advertisements' for the LAN( Bridge) interface. I then ensured that Services>DHCPv6>[LANBridge] is not enabled and that Services>Router Advertisements>[LANBridge] Router Advertisements is set to 'Unmanaged'.
What is interesting is that in Services>DHCPv6>[LANBridge] the subnet is 2a02:xxxx:xxxx:8800:: (sounds good?) but the subnet mask says 56 bits (I was expecting this to be 64bits, because Interfaces>WAN>DHCPv6 client configuration has a prefix delegation size of 64 bits)
This is also reflected in /var/etc/radvd.conf which is:
# Automatically generated, do not edit
# Generated RADVD config for manual assignment on lan
interface bridge0 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1500;
AdvDefaultPreference medium;
prefix 2a02:xxxx:xxxx:8800::/56 {
DeprecatePrefix on;
AdvOnLink on;
AdvAutonomous on;
};
RDNSS 2a02:xxxx:xxxx:8800:5a9c:fcff:fe10:6d75 {
};
DNSSL local {
};
};
I would have expected 'prefix 2a02:xxxx:xxxx:8800::/64' rather than 56.
In this configuration my clients only get a link-local IPv6 address - no public address
Could the /56 be the issue? And if so, any ideas on how to correct?
Thanks again
Yep, that is a problem, it should be /64.
Could you take a look at Interfaces->WAN, "DHCPv6 client configuration" tab "Advanced" and see what you see under "Prefix Interface Site-Level Aggregation Length"? In your specific case, I think it should be 0 instead of 8, because you cannot strip any more bits for an interface prefix from the 64 bits you have.
Quick update:
I was thinking about the /56 subnet in /var/etc/radvd.conf and, just to play, went to Interfaces>WAN and set the ' Prefix delegation size' to 56 (it was 64 because that is what I believe my ISP issues - and what my old Draytek reports).
With the WAN interface set to 56, the subnet /var/etc/radvd.conf becomes 64 and magically the clients get/generate two IPv6 global addresses and 1 link local, just as I wanted.
So my problem is solved, but I'd love to understand what is going on. Is it possible my ISP is actually issuing a /56? And I definitely don't understand why setting a 56 prefix in WAN gives me a /64 in DHCPv6 and radvd.conf. And vice-versa too - setting a /64 prefix in WAN gives a subnet of 56 in DHCPv6 and radvd.conf.
If someone could enlighten me I'd be really grateful.
Thanks
Quote from: meyergru on November 17, 2023, 11:30:39 AM
Yep, that is a problem, it should be /64.
Could you take a look at Interfaces->WAN, "DHCPv6 client configuration" tab "Advanced" and see what you see under "Prefix Interface Site-Level Aggregation Length"? In your specific case, I think it should be 0 instead of 8, because you cannot strip any more bits for an interface prefix from the 64 bits you have.
Thanks. I just switched WAN 'Prefix delegation size' back to 64 bits amd checked 'Advanced'. All the settings, including Prefix Interface Site-Level Aggregation Length, are blank. I've set it to 0 and when I checked its removed all the IP addresses from radvd.conf:
# Automatically generated, do not edit
# Generated RADVD config for manual assignment on lan
interface bridge0 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1500;
AdvDefaultPreference medium;
DNSSL local {
};
};
Just to check if I am receiving a /56 subnet from my ISP, rather than a /64, I turned off ' Request only an IPv6 prefix' and 'Send IPv6 prefix hint' on the WAN interface.
My theory was that if the ISP is issuing a /64 things would break - because the WAN interface would get a global rather than link-local address, and there wouldn't be a subnet for the LAN.
Things didn't break. In the dashboard, my WAN interface gets a very different address to the LAN:
WAN: 100.75.x.x (CGNAT)
xxxx:6b68:0:183::7d
LAN:192.168.0.1
xxxx:6b6c:9800:8e00:yyyy:fcff:fe10:6d75
I don't fully understand it yet, but it works, so I am assuming that I get a 56 from my ISP.
Thanks everyone.
PS: Is there any mileage in me writing up a 'how to' for this ISP? And if so where should I put it?
It seems your ISP actually delegates a /56, yes. Which is unsurprising, this is the most common prefix length for consumers. To double check, you can see the delegated prefix in Interfaces: Overview: WAN.
The prefix length of tracking LAN interfaces should always be /64, SLAAC doesn't work with any other prefix length. It seems this gets set incorrectly if the configured prefix delegation size doesn't match the actual prefix length. I'll have a look later, but it's not unreasonable that an incorrect configuration results in unexpected behaviour (though this could probably be handled more gracefully).
The WAN address is unrelated to the delegated prefix. It often is in a completely different subnet and requesting one has no impact on prefix availability. The setting to only request a prefix is for ISPs who use SLAAC for numbering the WAN interface.
I don't think a new how-to is required. Your ISP seems to use the most common setup there is: A /56 prefix delegation and a /128 WAN address assigned via DHCPv6. It doesn't get more basic than this. ;)
Cheers
Maurice
Thanks Maurice
Yes, it is a basic config - it just didn't feel it at the time!. :)
In reality, this was all down to me reading in multiple places that my ISP delegates a /64 which turned out to be untrue (most likely they have changed it over time). Being new to OPN I didn't think about Interfaces: Overview. WAN. Yes, it's /56.
<<The WAN address is unrelated to the delegated prefix.>>
That is useful to know. I have actually checked the WAN interface 'Request only an IPv6 prefix' again. I figure the WAN interface doesn't need a global address, and is potentially more secure without one. Please correct me if I'm wrong.
Overall, I am really impressed with OPNsense. Having used several Juniper SRX devices at work, I find it lovely to be using a responsive, well thought out web interface (J-Web is a nightmare you quickly ignore in favour of the CLI and configs). I don't have any issue with incorrect configuration resulting in unexpected behaviour - that's true of most platforms!
Thanks again - now the basics are working well, I can move on to VPNs etc.
A WAN address is required (well, useful) if you want to access services running on OPNsense itself from the Internet. Typical example is VPN.
And of course OPNsense needs a source address for things like DNS queries, downloading updates, NTP and so on. While it can use a LAN interface address for this, I'd recommend having a routable address on the WAN interface whenever possible.
Thanks again Maurice
Good point - especially for a VPN. I would soon realise that when I come to set one up! I'll do it now, so I don't forget.
You do not really need a WAN IPv6.
For example, if your ISP only delegates an IPv6 prefix, but no WAN address (mine does this), only your LAN interface(s) gets an IPv6 GUA. That is no problem, because you can use that for IPv6 traffic originating from and destined to the firewall itself.
Good point. Thanks
Can the LAN GUA also be used as a source address for OPNsense things like DNS queries, downloading updates, NTP and so on? I didnt see any issues before I turned off 'Request only an IPv6 prefix', but I didn't test updates etc.
If you can't get a WAN address, a LAN interface address works, too. It has some caveats though. What if the LAN interface is down etc.? I see no reason not to use a WAN address if you can easily get one (which seems to be the case for @macklij).
There have been some requests to allow the WAN interface to track its own delegated prefix to create a WAN address. That would be a good solution for ISPs like @meyergru's.
Yup, we discussed that and Franco tried to make it work, but it was more difficult than expected.
Luckily, my LAN interface is always up, so I can live with that. I would use it only in a pinch, however.
From this I take it Meyergru gets a /64 from his ISP? Otherwise wouldn't rely on the LAN GUA?
Quote from: Maurice on November 17, 2023, 03:28:20 PM
If you can't get a WAN address, a LAN interface address works, too. It has some caveats though. What if the LAN interface is down etc.? I see no reason not to use a WAN address if you can easily get one (which seems to be the case for @macklij).
There have been some requests to allow the WAN interface to track its own delegated prefix to create a WAN address. That would be a good solution for ISPs like @meyergru's.
For those addresses you should use loopback interfaces, not physical ones.
@macklij No. As mentioned, the WAN address typically is outside of the delegated prefix and assigned by the ISP independently (via DHCPv6 IA_NA or SLAAC). The size of the delegated prefix is unrelated to this. But some ISPs only offer a prefix and no WAN address at all (luckily not yours). In such a case, one can use the delegated prefix to create a WAN address (which is then inside the delegated prefix). Unfortunately, OPNsense doesn't support this (yet).
@bimbar A loopback interface with track6 configuration? Interesting idea. Could work.
Quote from: macklij on November 17, 2023, 03:48:48 PM
From this I take it Meyergru gets a /64 from his ISP? Otherwise wouldn't rely on the LAN GUA?
No, I get /56, but only an IPv6 prefix, no IPv6 GUA on the LAN interface. OpnSense has no means (yet) to assign a prefix to the WAN interface. Usually the DHCPv6 client tries to get both a prefix for delegation (IA_PD) and a WAN IPv6 (IA_NA). My ISP does not hand out anything at all if I ask for that, so by using the setting "Request only an IPv6 prefix", I get a /56 prefix only and make do by using the LAN IPv6 GUA instead.
@meyergru
@Maurice
Thanks for the explanations. I am beginning to get my head around IPv6. Probably enough to be a danger to myself. :D
Quote from: bimbar on November 17, 2023, 03:50:02 PM
For those addresses you should use loopback interfaces, not physical ones.
I now tried this and it doesn't work. Loopback interfaces don't have a MAC address, so EUI-64 isn't possible. As a result, setting a loopback interface to "Track Interface" mode entirely breaks dhcp6c:
Notice dhcp6c link layer address is too short (lo1)
Notice dhcp6c failed to get default IF ID for lo1
Error dhcp6c failed to parse configuration file
I must be missing the grand idea behind turning a perfectly working setup into a collection of completely unneeded broken hacks.
You do NOT need GUA on WAN. Just move on.
Quote from: Maurice on November 18, 2023, 12:52:55 AM
Quote from: bimbar on November 17, 2023, 03:50:02 PM
For those addresses you should use loopback interfaces, not physical ones.
I now tried this and it doesn't work. Loopback interfaces don't have a MAC address, so EUI-64 isn't possible. As a result, setting a loopback interface to "Track Interface" mode entirely breaks dhcp6c:
Notice dhcp6c link layer address is too short (lo1)
Notice dhcp6c failed to get default IF ID for lo1
Error dhcp6c failed to parse configuration file
You probably need a static prefix for that, but it would be the right way to do it, if it is possible.