No IPv6 address assigned on WAN interface / Router Advertisement ignored

[glasi]

Hi all,

my OPNsense is not assigned an IPv6 address on the WAN interface after starting, but is only assigned after 10 minutes.

As configuration type I use PPPoE for IPv4 and SLAAC for IPv6.

A packet dump is showing that the OPNsense and the provider successfully exchange and acknowledge their interfaces identifiers via PPP IPV6CP. After about 5 seconds, the provider sends a Router Advertisement with information on DNS servers and IPv6 prefix via ICMPv6 . However, OPNsense does not respond to this Router Advertisement.

Another Router Advertisement from my provider 15 seconds later is once again ignored by OPNsense. Hence, I won't get assigned an IPv6 address on the WAN interface.

There seems to be a race condition as OPNsense is not reacting on Router Advertisements during startup process.

To get an IPv6 address assigned on my WAN interfance, I'll have to wait 10 minutes till my provider sends a new Router Advertisement. This Router Advertisement is now being answered by OPNsense with a Neighbor Solicitation message.

Furthermore, there is an issue with DynDNS. I've noticed that the update script is called during the startup process, however at this point in time there is no IPv6 address on the WAN interface. If the IPv6 address is then assigned later (after 10 minutes), the script does not appear to be called any more.

Does anyone have an idea how to solve these issues.

Regards
glasi

[schnipp]

My Opnsense also suffers from this problem. Assigning of an IPv6 prefix takes very long time, though a packet dump shows that the provider immediately sends router advertisement messages after establishing the pppoe connection. But the Opnsense does never send any router solicit messages.

So, it seems that first advertisement messages get lost, because after receiving a third one after 8 to 10 minutes the WAN interface itself assigns an IPv6 address.

The waiting time can be reduced by manually triggering a router solicit message by executing "rtsol" command in the terminal.

Regarding dyndns my Opnsense shows the same problem not updating the the dynamic dns for IPv6 after an IPv6 address has been assigned to the WAN interface.

[glasi]

Thank you for the tip with rtsol command.

I can confirm that a Router Solicitation message is being send when executing rtsol. The provider is then sending DNS server and IPv6 prefix information via Router Advertisment message. OPNsense is responding via Neighbor Solicitation message.

This raises two questions:

1) Why doesn't OPNsense automatically send any Router Solicitation messages?
2) Why is the DynDNS update script not being triggered?

[glasi]

Things seem to get a bit messy.

Further analyses are showing that OPNsense does not send any Router Solicitation messages when "Use IPv4 connectivity" option is enabled for IPv4 Configuration Types SLAAC or DPHCv6.

In contrast, Router Solicitation messages can be seen in the packet dump file when "Use IPv4 connectivity" option is disabled. However, OPNsense is then sending the Router Solicitation messages via the wrong interface. Instead of using my PPPoE interface, OPNsense sends these messages via the parent interface ix0_vlan7 without PPPoE encapsulation. That's like sending to /dev/null.

As the documentation is not 100% clear on this, I can't say for sure whether or not it's intended that the parent interace will be used when the option "Use IPv4 connectivity" is disabled (can we be sure that interfaces.inc is doing the right things?).

Nevertheless, Router Solicitation messages should definitely work when "Use IPv4 connectivity" option is enabled.

IMHO, it's a bug.

[marjohn56]

Then raise it on Github.

[glasi]

I did some further analysis.

The problem with the missing router solicitation messages first appeared with version 20.7.

With older versions (e.g. 19.7, 20.1) router solicitation messages are sent without any problems.

BTW I've tested the latest version of pfsense (v. 2.5.0) with identical settings. And pfsense sends router solicitation messages without any problems.

So this is definitely broken in OPNsense > 20.1.

[franco]

You'll be fine in the self-proposed competency of pfSense 2.5, I'm sure.

To me this sounds like beating a dead horse with lengthy discussions and solutions for other use cases already in place.

Yes, we know there is an issue with FreeBSD 12.1-RELEASE and, yes, pfSense is using a 12.2-STABLE release that has no official FreeBSD release engineering process and, yes, FreeBSD errata almost never happens on RELEASE.

So is the issue fixed on FreeBSD 12.2 or 12.3? I don't know until someone can pinpoint the issue and upstream patch.

There is quite a lot of time sunk in chasing shadows with upstream so use what works and pray that there are no other issues that appear after 12.1. I guess we only see what we want to see. ;)


Cheers,
Franco

[glasi]

There is no need to be sarcastic. The hint that it works with pfsense 2.5 should be understood as constructive information.

Passing problems on to the upstream channel, i. e. FreeBSD 12.1, is just a bit cheap, isn't it?

And no, the problem for sure is not related to FreeBSD 12.1. As mentioned, router solicitation messages do work when the option "Use IPv4 connectivity" is deactivated. And they can also be successfully sent via rtsol command even when the option "Use IPv4 connectivity" is activated.

The problem can be pinpointed to code changes in interfaces.inc in 20.7.r.

Introducing autoprobing parameter (-a) for $rtsoldcommand in function interface_dhcpv6_configure is causing problems as rtsold fails detecting the correct outgoing interface.

Code Select Expand

rtsold: received RA from fe80::xxxx:xxxx:xxxx:xxxx on an unexpected IF(pppoe0)

Former versions were explicitly specifying the outgoing interface rather than using autoprobing.

And I don't see any reason why we should rely on autoprobing at all.

[marjohn56]

I think the difference here is from my memory of using pfSense and the work I did around dhcp6c on that system it uses rtsol with the name of the interface that's being configured.

I have just completed some testing using a VM of Microtik RouterOS acting as a PPPoE server and sure enough there is no router solicitation sent from Opnsense over the PPPoE interface, however sending a one shot command using rtsol provides the RS and away we go. Looking further into RTSOLD we are using the -a flag which probes all non point to point interfaces, forgive me if I'm wrong, but pppoe is a point to point interface.

Anyway, I replaced the -a with pppoe0 and igb0 ( my test wans ) and sure enough a solicit is sent on the pppoe & igb0 interfaces, I'll raise this as an issue and post my patch later.


https://github.com/opnsense/core/issues/4733

[glasi]

Marjohn56,

I am relieved that you could reproduce the problem.

Thanks a lot for creating a Github ticket. Because I have to admit that Github is a black box for me.

As a non-professional programmer I am already more than happy that I could identify rtsold autoprobing as a potential cause for this issue. I invested quite some time to get there.

Nevertheless, I'll spend some time on Github Guides and Tutorials to gain some Github knowledge.

Regards,
glasi

[marjohn56]

There is a patch there now, if you want to try it the command is:


opnsense-patch c0b7165


I've updated it in the last few minutes as I've added a check to make sure the interfaces is enabled, don't want to be sending out packets on an interface that's not!

[franco]

https://github.com/opnsense/src/commit/2485dc0351e

I'm outta here and wholeheartedly recommend any other solution if a one liner for a 9 month old patch that already made it to two production releases is causing such a belated fuzz. It's really not worth any more time.


Cheers,
Franco

[marjohn56]

I for one was not aware that rtsold had been patched, hence I was going by the man pages.


I don't think it's belated, I think it may be related.... to other issues.

[glasi]

There is a patch there now, if you want to try it the command is:


opnsense-patch c0b7165


I've updated it in the last few minutes as I've added a check to make sure the interfaces is enabled, don't want to be sending out packets on an interface that's not!

The proposed patch works like a charm. Router solicitation messages are now send via correctly identified interface pppoe0.

[franco]

> As configuration type I use PPPoE for IPv4 and SLAAC for IPv6.

So the PPPoE is too slow to come up as we try to immediately start dhcp6c anyway. We cannot expect to keep all quirks for ISPs alive if we change code to accommodate other setups.

> The proposed patch works like a charm. Router solicitation messages are now send via correctly identified interface pppoe0.

It's not happening.


Cheers,
Franco