6RD Default Route Issue (19.7.5, 20.1, 20.7, 21.1.a_201)

[franco]

This should be it https://github.com/opnsense/core/commit/f4e2728b81

# opnsense-patch f4e2728b81

Really hard to find without a test setup so again thank you very much!

The /64 is trickier because in normal routing you want a bigger net on the WAN and a smaller one on the LAN but in this case you only have one and you need to give it to LAN so it thinks it's upstream connected... I will look into it as time permits.


Cheers,
Franco

[mhofer]

Hi Franco

Thanks a lot for the quick investigation!

Unfortunately, your patch does not yet work.
The reason is that the WAN interface is igb0, but the STF interface gets created with the wan interface key (opt2) as prefix instead of igb0, so it is ccalled opt2_stf and /tmp/opt2_stf_routerv6.
However the code currently checks for /tmp/igb0_stf_routerv6.

For now i patched it as follows to make it work:

Code: [Select]

diff --git a/src/opnsense/mvc/app/library/OPNsense/Routing/Gateways.php b/src/opnsense/mvc/app/library/OPNsense/Routing/Gateways.php
index d17bc382c..4a88ba6cf 100644
--- a/src/opnsense/mvc/app/library/OPNsense/Routing/Gateways.php
+++ b/src/opnsense/mvc/app/library/OPNsense/Routing/Gateways.php
@@ -245,6 +245,13 @@ class Gateways
                         }
                         $gwkey = $this->newKey($thisconf['priority'], !empty($thisconf['defaultgw']));
                         $this->cached_gateways[$gwkey] = $thisconf;
+                    } elseif (file_exists("/tmp/{$ifname}{$isuffix}_router{$fsuffix}")) {
+                        $thisconf['gateway'] = trim(@file_get_contents("/tmp/{$ifname}{$isuffix}_router{$fsuffix}"));
+                        if (empty($thisconf['monitor_disable']) && empty($thisconf['monitor'])) {
+                            $thisconf['monitor'] = $thisconf['gateway'];
+                        }
+                        $gwkey = $this->newKey($thisconf['priority'], !empty($thisconf['defaultgw']));
+                        $this->cached_gateways[$gwkey] = $thisconf;
                     } elseif (!empty($ifcfg['gateway_interface']) || substr($ifcfg['if'], 0, 5) == "ovpnc") {
                         // XXX: ditch ovpnc in a major upgrade in the future, supersede with interface setting
                         //      gateway_interface

An alternative might be to change the code where the /tmp file is written.

Regards,
Marcel

[madj42]

Kind of a stupid question but figured ask anyway.  I am assuming these patches should work on 21.1 as it is now?  I'm waiting for the issue to be completely figured out but wanted to make sure before trying to apply it.

[franco]

Hi Marcel,

You are right. We tried to rename the interfaces/files once but the interface name limit can be too short, see: https://github.com/opnsense/core/issues/3222

So here is the missing link with the fallback to config interface name:

https://github.com/opnsense/core/commit/866ec6df74

@madj42: I want this routing fix in the final 21.1 next week. The /64 tracking fix I cannot quickly make promises but Marcel already signalled to help with the remote testing.


Cheers,
Franco

[madj42]

I'm not sure I can help with the 64 tracking issue but what I can help with is testing this against my instance I have running on 21.1 production channel.  Would I be alright implementing these two patches together on that?   Assuming I need both from what it looks like?

Trying to offer up another test system since my provider uses RD (I hate it and I wish they would change).

Thank you both for the help in solving this!  I have been using HE for awhile to get around this pain point and would like to switch back.

[madj42]

Decided to bite the bullet and just do it as it could be reversed.  Disabled my HE tunnel and plugged in the RD settings
  Fired right up and I'm up and running.  I'll reboot tonight to test that out.  Thank you both again and if I can help testing anything, else I would love to.  So far this version of 21.1 has been rock solid.

[mhofer]

I can confirm on opnsense-20.7.8, with:

Code: [Select]

opnsense-patch f4e2728b81 866ec6df74the ipv6 default route for 6rd is recognized again!

[franco]

Super, thanks for confirming! Backported to 21.1 via https://github.com/opnsense/core/commit/30645c77fa

A snapshot update goes out to 21.1-RC1 in about an hour that will already include the fix. 21.1 follows on Thursday according to the current schedule.


Cheers,
Franco

[mhofer]

Hi

I think I have a proper solution for my /64 issue.
Instead of setting the calculated /64 subnet length on the _stf interface, I set the original ISP provided subnet length.
And change the gateway to be inside the ISP provided prefix instead of the calculated /64.

https://github.com/mhofer117/core/commit/bbad554d3c

Together with the patches from franco, it is working great so far with connectivity on LAN and from the firewall itself.

@madj42 are you willing to test this on your setup too?

Code: [Select]

opnsense-patch -a mhofer117 bbad554d3c

Regards,
Marcel

[franco]

Hi Marcel,

Looks clever: keep WAN address but widen the prefix anyway -- upstream gateway won't care and ISP prefix routing will do the rest from firewall perspective.

Will you open a PR? Can add this to master branch (development version) of 21.1 surely. If madj42 confirms we will add to production version also.


Thank you,
Franco

[mhofer]

I have just created the PR: https://github.com/opnsense/core/pull/4635

[madj42]

@franco, assuming you just want me to patch my system and report back that it doesn't break anything on my end even though I'm not having the same issue as mhofer?

If so, I'll patch it and reboot after work.

UPDATE: I had some time on a break and patched the system.  Patched the system and rebooted.  All appears to be working but I'd like to see if I notice anything overnight.  I'll be sure to update this post tomorrow.

Also once this is added in, I'm assuming this will be in the development channel and not in the 21.1 production one until Thursday?  Didn't know if you wanted me to test something in the development channel after it's merged just to be sure there are no issues when the production release is released.

[franco]

Yes, indeed, that is valuable feedback to rule out a regression on a similar but unaffected setup. Ideally this can go to 21.1 release (not development) now if it works. Since 6RD is in a twilight state with 20.7 anyway and we do not affect 20.7.x users anymore there is a window of opportunity to simply ship an improved 21.1 image.

I'm not sure when you want to update this thread tomorrow as we are going to be kicking the final build around 11 UTC, but appreciate the heads-up anytime.

Again, thanks for this perfect last minute community patch session!


Cheers,
Franco

[mhofer]

Thanks alot madj42 for testing!
And Thank you very much franco for the quick and constructive patch session =)

Will be nice to see 6rd fully functional again in the next release.

[madj42]

I apologize, the entire day was busy.  I think we are good as there haven't been any issues here on my end.  Did the latest push to the production channel of 21.1 include the fix?

Thanks again!