interfaces: allow tracking the WAN itself in DHCPv6 mode

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
I have searched the existing issues, open and closed, and I'm convinced that mine is new.
When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.
When using dhcp6c over a PPPoE link, if the ISP hands out IPv6 prefixes only, but no IPv6 interface address (i.e. "send ia-na 0" is not honored), the WAN interface gets no IPv6 assignment at all.
Thus, one is limited to the IPv6 addresses of other interfaces that use "track6".

However, without an IPv6 on the WAN interface, FreeBSD does not honor the "highest address" rule of IPv6 in case that several other IPv6 addresses are available for use as a source address. Thus, you basically have no control over which interface's address will get used for outgoing connections from the firewall itself - e.g., assigning a higher IPv6 prefix ID does nothing.

If you register with a dynamic DNS service, you probably want to identify the IPv6 prefix for a specific VLAN interface. The prefix will be arbitrary, though.

Describe the solution you'd like
It would be nice if track6 and dhcp6c were not mutually exclusive. If the interface configuration that originates from "track6" could also be generated for "dhcp6c" via a GUI checkbox, one could hand out an IPv6 prefix to the WAN interface even if the ISP does not offer a separate IPv6 for the interface itself. In that case, the WAN IPv6 would get used unconditionally before any other IPv6 addresses.

Describe alternatives you've considered
I can see no option to assign IPv6 to the WAN interface in this situation.

Additional context
It would also be nice to be able to use IPv6 privacy extensions from the firewall itself. This is not possible with dhcp6c or track6, I believe.

I think that's what "advanced" is for... check "Identity Association" section of the settings.

When I use that, the section for "id-assoc pd 0" still does not contain the WAN interface. The content of that section is exactly described by all interfaces that use "track6". I can only modify the sla-len, but not the interfaces listed there.

Shouldn't you set "Non-Temporary Address Allocation" here for WAN? The prefix (pd) is intended for downstream devices only according to the code.

Correct. That is my point. My ISP (M-Net) does not honor "send ia-na 0". They give out only a /56 prefix via "send ia-pd 0", but not an additional IPv6 for the PPPoE interface itself. Thus, it would be nice to use part of the prefix range for the PPPoE interface, like I can for all other interfaces. Currently, this is impossible because I cannot use both "track6" and "dhcpc6" for WAN.

However, without an IPv6 on the WAN interface, FreeBSD does not honor the "highest address" rule of IPv6 in case that several other IPv6 addresses are available for use as a source address.

How is this tested locally on the command line? I'm happy to test.

I have multiple VLAN interfaces that use track6, like so:

ax0_vlan107: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: IOT
        options=4000300<TSO4,TSO6,NOMAP>
        ether f4:90:ea:00:74:49
        inet 192.168.107.1 netmask 0xffffff00 broadcast 192.168.107.255
        inet6 2001:a62:3bbb:207:f690:eaff:fe00:7449 prefixlen 64
        inet6 fe80::f690:eaff:fe00:7449%ax0_vlan107 prefixlen 64 scopeid 0xc
        groups: vlan RESTRICTED
        vlan: 107 vlanproto: 802.1q vlanpcp: 0 parent interface: ax0
        media: Ethernet autoselect (10GBase-SFI <full-duplex,rxpause,txpause>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
ax0_vlan4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: GAST
        options=4000300<TSO4,TSO6,NOMAP>
        ether f4:90:ea:00:74:49
        inet 192.168.4.1 netmask 0xffffff00 broadcast 192.168.4.255
        inet6 2001:a62:3bbb:204:f690:eaff:fe00:7449 prefixlen 64
        inet6 fe80::f690:eaff:fe00:7449%ax0_vlan4 prefixlen 64 scopeid 0xd
        groups: vlan RESTRICTED
        vlan: 4 vlanproto: 802.1q vlanpcp: 0 parent interface: ax0
        media: Ethernet autoselect (10GBase-SFI <full-duplex,rxpause,txpause>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
ax0_vlan5: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: DMZ
        options=4000300<TSO4,TSO6,NOMAP>
        ether f4:90:ea:00:74:49
        inet 192.168.5.1 netmask 0xffffff00 broadcast 192.168.5.255
        inet6 2001:a62:3bbb:205:f690:eaff:fe00:7449 prefixlen 64
        inet6 fe80::f690:eaff:fe00:7449%ax0_vlan5 prefixlen 64 scopeid 0xe
        groups: vlan RESTRICTED
        vlan: 5 vlanproto: 802.1q vlanpcp: 0 parent interface: ax0
        media: Ethernet autoselect (10GBase-SFI <full-duplex,rxpause,txpause>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

My WAN interface has no routable IPv6:

pppoe0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1492
        description: WAN
        inet6 fe80::f690:eaff:fe00:7446%pppoe0 prefixlen 64 scopeid 0xf
        inet 188.174.51.22 --> 82.135.16.28 netmask 0xffffffff
        nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>

When I try: "curl https://api64.ipify.org", I see:

2001:a62:3bbb:205:f690:eaff:fe00:7449

which is clearly ax0_vlan5 instead of ax0_vlan7, which has a higher IPv6 because I chose 0x07 as the IPv6 Prefix ID for that interface. This is considered general IPv6 behaviour, but not in FreeBSD, see 8.1.1.6, case 3, here: https://docs.freebsd.org/de/books/developers-handbook/ipv6/ . In case 2, where WAN interface has an assigned IPv6, that would be preferred.

While the source cited also says that the choice between equal-ranked interfaces is "up to implementation", it clearly should not be:

https://datatracker.ietf.org/doc/html/rfc6724#page-11

The source address selection should be the highest IPv6 - at least that is what I understood. I have not yet found which interface gets selected, probably the last one assigned? At least I have found no way to influence the choice.
This would never be neccessary if PPPoE gets an IPv6 address...

Looking at https://reviews.freebsd.org/D709 ifconfig supports prefer_source. Have you tried this yet?

Apart from right or wrong I'm still a bit unsure what should be achieved from this. You don't know which interface will take the address / the wrong interfaces takes the address you prefer? If yes, the above could help fix that.

Yes, I found that one, too. However, it works only if you already know the IPv6, you cannot "prefer_source" an interface by name. So, I cannot do assign the attribute automatically - or this would have to be integrated into OpnSense scripts.

And: yes. I would like to control which address / interface calls out. That way, you could provide to have dyndns for devices behind the firewall (by just changing the prefix part and leaving the hardware part unchanged). OpnSense would do the dyndns updates and devices become addressable over the internet.

This would offer a means to have something like port forwarding, but with IPv6 for ISPs that support only DS-Lite or CGNAT. I guess one could use 72 bits (i.e. 8 Bits Prefix ID plus 64 Bits hardware part) instead as fixed and only modify the /56 Prefix.

I see your point but it looks like our hands are a bit tied with regard to what the OS is actually offering here. I'm not convinced that tainting the WAN with a PD-subnet is the best course of action.

Another approach would be to add prefix expansion to VIPs (it was discussed a bit last year) which could add the prefer_source flag reliably. Still the prefix merge for a VIP is a little opportunistic since we don't know when a prefix/address appears and when it goes away (indirectly yes but also not 100% reliable).

Cheers,
Franco

But "tainting the WAN with a PD-subnet" with prefix ID 0x00 is exactly what an AVM Fritzbox does as a fallback (see https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/IPv6_Technical_Note_de.pdf at the end of page 4):

An attempt is made to derive the WAN address from the provider's router advertisement.
If information about DNS servers is available in the router advertisement (RFC 5006), this is adopted.

Then, a globally valid prefix (IA_PD) for the home network is requested via DHCPv6.
If no global WAN address could be determined for the FRITZ!Box in step 1,
such an address is now requested via DHCPv6 (IA_NA).
DNS and NTP servers are also requested via DHCPv6 (DNS_SERVERS, NTP_SERVER),
if none are known from step 1.

If still no WAN address is known, the first /64 network from the assigned
LAN prefix is used for the WAN interface of the FRITZ!Box.

M-Net does neither offer 1 nor honor 2, and OpnSense does not allow 3 - easy as that.

In Germany, there seems to be at least one other ISP like M-Net who does not offer IA_NA: https://forum.openwrt.org/t/solved-how-to-configure-ipv6-pppoe-connectivity/36923

I think a checkbox option to "track6" the dhcp6c interface would be the way to go. That way, the weakness of those providers could be circumvented. AVM does just that, albeit not as an option but automatically. I admit that one still has to go the route of having a fixed 72 Bit wide "prefix id + hardware part" in dynamic DNS in order to make devices on a VLAN with a specific prefix ID available. That in itself is kind of a problem, because limiting access to a specific host can neither be done based upon its IPv6 with dynamic prefixes nor via its MAC, see: https://forum.opnsense.org/index.php?topic=27483.0.

I guess it is difficult to impossible to open an IPv6 port on a host behind OpnSense... or maybe I am trying the wrong way.

I guess it is difficult to impossible to open an IPv6 port on a host behind OpnSense... or maybe I am trying the wrong way.

For majority of non-business type ISP IPv6 that do not offer fixed IPv6 address/PD... yes.

Opening up ports via IPv6 would be a nice feature for OpnSense, still (hate to think that AVM has it).

Thank you, Franco!

You mean the approach mentioned #4430 (comment)? Might be worth giving a try 😃

No, now the kernel says if auto_linklocal is set and the link-local is removed and the interface brought down and up again it will assign a new link-local automatically. I tested this with a faked ether MAC address and it does indeed use faked one rather than the original hwaddr MAC address. So addressing this loophole in the configuration code should be easy enough. I don't see a big need for removing auto_linklocal. It's just not going to end well. The bridge is a special case where it't not on by default so the option was added there to enable a defined use case.

Really? It was already a stupid limitation when I moved from PHP to .NET 15 years ago

Yes. Seems to be the law of the land... there's only so much space in a signed integer and since we don't have 28 bit architectures it is what it is. This can all be improved/worked around but the time is better spent elsewhere at the moment.

Thanks a lot for the time you dedicated to these nice - but niche? - features. Much appreciated! ❤️

Not that niche judging by the questions over the years, but also not well researched and implemented in open source. This is pretty cutting edge now.

Edit: I applied 30df142 and rebooted, still working fine 👍🏻

Perfect. Ready for the 24.7 beta images then. :)

Cheers,
Franco

No, now the kernel says if auto_linklocal is set and the link-local is removed and the interface brought down and up again it will assign a new link-local automatically. I tested this with a faked ether MAC address and it does indeed use faked one rather than the original hwaddr MAC address.

Nice, I'll keep an eye on the other thread then 😃

Not that niche judging by the questions over the years, but also not well researched and implemented in open source. This is pretty cutting edge now.

Yeah, definitely. AFAIK, only systemd-networkd currently has a pretty well-integrated and simple story for that (by simple, I mean you don't have to write custom scripts 🤣).

Should be something like...

[Match]
Name=wan

[Network]
DHCP=yes
IPv6AcceptRA=yes
IPv6SendRA=no
DHCPPrefixDelegation=yes

[DHCPv6]
UseDelegatedPrefix=yes
PrefixDelegationHint=::/56
WithoutRA=solicit

[DHCPPrefixDelegation]
UplinkInterface=:self 
SubnetId=0x01 # Equivalent of sla-id in dhcp6c
Announce=no
Token=::1111:2222:3333:aaaa # Equivalent of ifid in dhcp6c

But of course, it's a Linux thing, so not something OPNsense could benefit from (unless you plan to work on a Linux version at some point? 🤣)

I checked the last version now and it works nicely. So it's ready for 24.7. Closing this issue now.

I still have to tweak the wording and update the docs :)

@meyergru

Last version for a while:
# opnsense-revert -r 24.1.8 opnsense && opnsense-patch 30df142 && opnsense-revert -z dhcp6c
@meyergru @kevinchalet thanks for all the input and testing!

Cheers, Franco

It works perfectly. Thank you very much for addressing this!

BTW: It doesn't seem to be a niche issue. My Vodafone VDSL in Berlin doesn't work properly without this fix either.

@meyergru

@meyergru Did you manage to get Opnsense to work with M-Net and IPv6 after the update ? I had problems after updating that it would connect successfully via PPPoE and give me a link local address but then never gave me a public routable one. Had to go undust the AVM router as a workaround for now.

Yes, perfectly. I use these settings for IPv6 (it is a fibre connection with "real" IPv4, not CG-NAT):

Optional prefix ID: 8-bit value, different from any other "track interface"
Optional interface ID: as you like if you want something different from the WAN EUI-64

I have fiber with CG-Nat for IPv4, and seems like that now has issues. I tried with your settings but still couldn't get past getting a link local address for IPv6. Is there any way for me to provide logs to further analyze this ?

@fichtner

I obviously cannot help with this, because I have the so-called "IPv4 option" (never got CG-NAT / DS-Lite running, not even with my previous Edgerouter). You can request it here: https://forum.m-net.de/viewtopic.php?f=20&t=8886 - I think with the larger rates, you get it for free.

Other than that, @fichtner has already told you to open a separate ticket.

@fichtner

Other than that, @fichtner has already told you to open a separate ticket.

I totally forgot about that, whoops, my bad.

I did make some progress by now though, and can confirm that DS-Lite from M-Net does work with Opnsense 24.7, it just needs a bit of workaround.

Here's how I do it (this presumes there already was a working GIF tunnel at some point)
After a boot:
Wait until IPv6 Link Local Address is acquired on the WAN interface (I used the same settings as posted above for the WAN interface, just with the "Request prefix only" unchecked)
Set LAN IPv6 to DHCPv6
Check that Router Advertisment Service is running, if not, try starting it again
Wait until GIF Tunnel comes up (this can sometimes happen in seconds or take literal minutes)
Set LAN IPv6 back to Track the WAN interface again

I did have a few more problems when I tried getting it to work on multiple LAN interfaces at the same time, but with only one this now works always for me.

It's def. an improvment to before 24.7 where I had to also manually bring up the GIF tunnel. As for the remaining issue that needs the workaround, I will open a separate ticket for that after searching through the open issues to check that there isn't already an existing one about this.

@fichtner

Other than that, @fichtner has already told you to open a separate ticket.

I totally forgot about that, whoops, my bad.

I did make some progress by now though, and can confirm that DS-Lite from M-Net does work with Opnsense 24.7, it just needs a bit of workaround.

Here's how I do it (this presumes there already was a working GIF tunnel at some point) After a boot: Wait until IPv6 Link Local Address is acquired on the WAN interface (I used the same settings as posted above for the WAN interface, just with the "Request prefix only" unchecked) Set LAN IPv6 to DHCPv6 Check that Router Advertisment Service is running, if not, try starting it again Wait until GIF Tunnel comes up (this can sometimes happen in seconds or take literal minutes) Set LAN IPv6 back to Track the WAN interface again

I did have a few more problems when I tried getting it to work on multiple LAN interfaces at the same time, but with only one this now works always for me.

It's def. an improvment to before 24.7 where I had to also manually bring up the GIF tunnel. As for the remaining issue that needs the workaround, I will open a separate ticket for that after searching through the open issues to check that there isn't already an existing one about this.

Thanks for the write-up. I am currently a bit "scared" - I ordered the DS Lite contract to be set up in December and I thought I could just use the pfsense guide from cybercyber. But apparently, this is not the case. Also, the separate v4 option (for full DS) seems to be gone from the order process. When I checked earlier this year, I am pretty sure, that it was an option.
@Zerwin Did you open up the issue yet? Maybe, if I am lucky, a workaround in OPNsense would be implemented by the end of December.

EDIT: The option is definately gone from the official first order process (at least for Internet 500):

But the pricelist (dated 25.04.2024) still has it as an option (and should still be orderable via the forum link from @meyergru):

EDIT2:

It's def. an improvment to before 24.7 where I had to also manually bring up the GIF tunnel. As for the remaining issue that needs the workaround, I will open a separate ticket for that after searching through the open issues to check that there isn't already an existing one about this.

This seems to be tracked in #7713 now.

The option ist still available, AFAIK. There is a thread about this in their forum. They also link to a form.

Navigation Menu

Repository navigation

interfaces: allow tracking the WAN itself in DHCPv6 mode #5630

119 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

interfaces: allow tracking the WAN itself in DHCPv6 mode #5630

Description

Activity

fichtner commented on Mar 14, 2022

meyergru commented on Mar 14, 2022

fichtner commented on Mar 14, 2022

meyergru commented on Mar 14, 2022

fichtner commented on Mar 14, 2022

meyergru commented on Mar 14, 2022

fichtner commented on Mar 14, 2022

meyergru commented on Mar 14, 2022

fichtner commented on Mar 15, 2022

meyergru commented on Mar 15, 2022

fichtner commented on Mar 15, 2022

meyergru commented on Mar 15, 2022

119 remaining items

fichtner commented on Jun 7, 2024

kevinchalet commented on Jun 7, 2024

meyergru commented on Jun 13, 2024

fichtner commented on Jun 13, 2024

Starkstromkonsument commented on Jun 14, 2024

Zerwin commented on Aug 1, 2024

meyergru commented on Aug 1, 2024

Zerwin commented on Aug 1, 2024

meyergru commented on Aug 1, 2024

Zerwin commented on Aug 2, 2024

TheDom42 commented on Oct 27, 2024

meyergru commented on Oct 27, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions