Messages

> igc1 and vlan01 are not currently assigned. Are you saying I'd drop the v6 configuration from WAN (pppoe1), assign vlan01 or igc1 to WAN6, and configure the 6rd from that?

Correct. I believe it would be vlan01. This should confirm it for you from the console:

# ifconfig wan_stf

Trial on 24.7.3_1:

• Removed the 6rd configuration from WAN (assigned to the pppoe interface), save, apply.  The 6rd prefix is removed from the routing table, but the wan_stf interface remains partially configured (it has the tv4rbr address still configured, but no inet6 address) and is the tsill default v6 route.
• Reboot, flushes out the wan_stf interface and the associated default v6 route.
• Assign the vlan interface under the pppoe interface to WAN6, enable. IPv4 configured as none, IPv6 configured as 6rd, save apply.  No stf interface gets configured.  Also notice the old 6RD gateway associated with WAN is still listed, marked as defunct. Delete.
• Reboot, still no stf interface.
• Repeat, but use the hardware igc interface under the vlan interface (under the pppoe interface), same result.
• Remove the WAN6 assignment, re-configure 6RD on the WAN assignment (as it was originally), and the stf interface returns with a correct 6rd configuration.

Searching logs for WAN6 I see this a bunch of times:

Code Select Expand

/interfaces.php: The command '/sbin/ifconfig 'opt6_stf' inet6 description 'WAN6 (opt6)' up' returned exit code '1', the output was 'ifconfig: interface opt6_stf does not exist'

So it seems like a code path to create the stf interface is getting missed in this scenario, but later code paths expecting to find it existing is being hit.

With 6rd configured on the WAN assignment (pppoe), the stf interface looks like:

Code Select Expand


wan_stf: flags=1004041<UP,RUNNING,LINK2,LOWER_UP> metric 0 mtu 1280
description: WAN (wan)
options=0
inet6 2602:<redacted>:: prefixlen 24
groups: stf
v4net 0.0.0.0/32 -> tv4br 205.171.2.64
nd6 options=103<PERFORMNUD,ACCEPT_RTADV,NO_DAD>


Interesting note about radvd. Are you using LAN interfaces to track the WAN? Just by memory I think it's true that for 6RD/6to4 there is no event to automatically reconfigure clients. Happy to fix that, but ideally with a ticket on GitHub.

Yes, tracking the WAN interface.  I can put together a ticket.

I'd still like clarification on the second half:

The important thing going forward is that these types of setups will no longer work on 25.1 in the way they are currently performed. In 25.1 you will have to delete 6RD from your WAN and create a separate "WAN6" interface from your "port" where PPPoE is running on (something like igb1 for example). There you chose IPv4 None and IPv6 6RD and it should work as before. That being said, the same should already work on all known OPNsense versions but it was favoured by be convenient two-in-one WAN configuration which, again, has been a source of great confusion for at least a decade.

Can you:

[...]
2. Confirm that the configuration suggestions works as well on your end?

I agree that the two-in-one WAN configuration feels like an abstraction-too-far from the actual topology of the plumbing underneath, leading to confusion. I had thought that the stf tunnel setup would make more sense as an independent "Other Types" interface configuration; make an stf device, assign it to WAN6 and configure as 6rd there. Ultimately, it doesn't seem coupled to the pppoe interface by anything than by the routing table, as far as I understand.

I'm not 100% sure I follow how I would set up what you describe on 24.7, but would like to try it out.  If I have:

igc1 - hardware interface connected to the provider's ONT (unassigned)
vlan01 - pppoe packates need to be tagged with vlan 201, so this is on igc1 (unassigned)
pppoe1 - on top of vlan01 (assigned as WAN)

igc1 and vlan01 are not currently assigned. Are you saying I'd drop the v6 configuration from WAN (pppoe1), assign vlan01 or igc1 to WAN6, and configure the 6rd from that?

@seacycle

Thanks for reaching out. TLDR: you're looking for https://github.com/opnsense/core/commit/947e61b1a5

# opnsense-patch 947e61b1a5

...

Can you:

1. Confirm that the patch works? I'd add that to 24.7.3 of course.
2. Confirm that the configuration suggestions works as well on your end?

Please don't go, we need you for this. :)

The patch does appear to work with the convoluted 6rd-over-pppoe-over-a-tagged-vlan that CenturyLink requires, thanks! (There are some issues with radvd not picking up the prefix reliably without a manual restart, but that pre-dates 24.7.)

@seacycle

Thanks for reaching out. TLDR: you're looking for https://github.com/opnsense/core/commit/947e61b1a5

# opnsense-patch 947e61b1a5

The long version: Oh boy. This is one of the effects of confusion that "IPv4 connectivity" has created, because 6RD and 6TO4 do not work over PPPoE at all. So this is a side-by-side configuration, which is pretty mind-boggling considering your ISP goes through the effort to bring you online via PPPoE tunnel and gives you IPv6 outside the PPPoE tunnel... ok, why not? ;)

I've always felt the disconnect between the "simple" 6rd selection in the WAN interface configuration, and the actual underlying plumbing it sets up to be somewhat confusing. I do think the 6rd/6to4 configuration would make more sense relegated to the "Other Types" section along with GRE and friends, more or less completely independently configured, with its own assignment and firewall rules, as you describe, and would absolutely endorse that approach going forward.

6rd over pppoe it is the jankiest of all configurations an ISP could possibly offer for v6. But at about 2.7 million broadband subscribers CenturyLink isn't quite in the completely ignorable category here in the US. (And their symmetric fiber ipv4 performance, where I am, blows Comcast away, for less than half the price.)

I'm going to assume 6RD still works on 24.7 despite the visibility glitch?

I'm only occasionally at the physical location of this router, which makes testing different WAN configurations difficult, but I should be able to verify by Thursday. I've got 24.7.2 in loaded up in a separate boot environment so I can flip back and forth easily.  What I recall from by brief testing was that (a) the wan_stf interface kept its configuration through the upgrade process and obtained a valid v6 prefix usable for outbound traffic from the router. But (b) that clients on the LAN side couldn't make v6 connections through the router to the outside. I didn't get as far as identifying where the failure was.

I updated from the latest 24.1 to 24.7.2 (no patches from this thread applied). I'm cursed by an ISP supporting only 6rd.  The 6rd tunnel configuration UI is completely missing from the PPPoE interface configuration in 24.7.2?  The IPv6 option shows up as "None" after the update. The wan_stf tunnel device does remain configured through the upgrade process, and gets an address from the ISP, but isn't passing outbound v6 traffic from the LAN side, though v6 from the router itself gets out fine.

I didn't have a lot of time to diagnose and rolled back to 24.1 (thank you zfs boot environments!) when I have more time at the physical location of the router.

Will 6rd tunnel support over a PPPoE interface be returning in some form?