[CALL FOR TESTING] PPPoE restructuring and IPv6 improvements

[franco]

Let's not make multiple wrongs a right. I want to continue testing PPP refactor patches.

To continue testing regression free changes on 24.7.2 community release please use:

https://github.com/opnsense/core/commit/77531748
https://github.com/opnsense/core/commit/7582088d

# opnsense-patch 77531748 7582088d

If you want to test full set of IPv6-only capability please use the development release bundled with 24.7.2 instead. There is actually a follow up patch that completely disables IPv4 in this case which isn't in the development release:

https://github.com/opnsense/core/commit/cb09c6671b

# opnsense-patch cb09c6671b


Cheers,
Franco

[Hendre]

Hey Franco,

I upgraded to 24.7.2, updated my IPv6 to reproduce the kernel panic we've been talking about. I was able to reproduce it.

I then applied patch above, IPv6 restored and NO kernel panic.

Cheers,
Hendre

[doktornotor]

To continue testing regression free changes on 24.7.2 community release please use:

# opnsense-patch 77531748 7582088d

Still working just fine.

[franco]

Should we ship both patches with 24.7.3 or do the first one in 24.7.3 and the second one in 24.7.4?


Cheers,
Franco

[doktornotor]

Well I'd say they make sense shipped together. Still wanted to test this with the VLAN tagging done on OPNsense instead of the bridged router if that's of any interest. Hopefully tomorrow, today's reboot quota exceeded 😂

[doktornotor]

Well I'd say they make sense shipped together. Still wanted to test this with the VLAN tagging done on OPNsense instead of the bridged router if that's of any interest. Hopefully tomorrow, today's reboot quota exceeded 😂

Done for the sake of trying to reproduce this issue, no luck. It's working for me. (Will keep the setup, after firmware upgrades, the router defaults to bridge but no VLAN, so it's more convenient anyway).

[seacycle]

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?

[doktornotor]

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?

I would suggest you comment on your use case on https://github.com/opnsense/core/issues/7446

Relevant commit: https://github.com/opnsense/core/commit/b2d9372b0f8b2583da90e1e294d88996539e1983

[franco]

@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'm going to assume 6RD still works on 24.7 despite the visibility glitch?

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:

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.


Cheers,
Franco

[doktornotor]

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?

Maybe they have done some "improvement" there - such as "no 6rd before you connect via PPPoE". 

[franco]

Maybe they have done some "improvement" there - such as "no 6rd before you connect via PPPoE". 

Please, don't even joke about it.


Cheers,
Franco

[doktornotor]

Please, don't even joke about it.

The IPv4 connectivity checkbox makes return... 

As for the rest, cannot test 6rd with the suggested setup. Could do 6to4 but that seems to go to via he.net pretty much everywhere I did try with traceroute 192.88.99.1, has been deprecated for 10 years or so and Google had hated it years before they've started with the let's make HE.net tunnels unusable stunt.

[seacycle]

@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.

[nanoguy]

Let's not make multiple wrongs a right. I want to continue testing PPP refactor patches.

To continue testing regression free changes on 24.7.2 community release please use:

https://github.com/opnsense/core/commit/77531748
https://github.com/opnsense/core/commit/7582088d

# opnsense-patch 77531748 7582088d

If you want to test full set of IPv6-only capability please use the development release bundled with 24.7.2 instead. There is actually a follow up patch that completely disables IPv4 in this case which isn't in the development release:

https://github.com/opnsense/core/commit/cb09c6671b

# opnsense-patch cb09c6671b


Cheers,
Franco

Ok, I've applied the first two patches mentioned above and now I have no IPv6 connectivity. My ISP gives me a dynamic /56 prefix on WAN but with the patches I no longer get one. When trying to revert the patches I get 1 hunk failed for interfaces.inc

[doktornotor]

You need to revert them in reverse order I'd say.