IPv6 track interface often fails after temporary DSL line failure

[skywalker007]

Team,
this is a problem I have for more than a year, so it is not specific to the current version. Nevertheless I wonder how to either fix it or work around it.
My setup is an external VDSL modem with OPNSense initiating a PPPoE session on it.
Unfortunately, the line is suffering from temporary instabilities. So it may break down and OPNsense re-establishes the connection a minute later. The problem I have is that in those cases, IPv6 adress assignment via track interface often fails. I assume this i some kind of timing problem. I can manually fiy this by reloading the PPPoE  via Interfaces->Overview->WAN-> PPPoE reload.
However this is a cumbersome manual procedure.
Any ideas?

thanks, Till

[bartjsmit]

Hi Till, are you allowing all ICMPv6 on the WAN interface? You may be blocking some multicast from your ISP.

Bart...

[tiermutter]

I had the same issue for years. I am not really sure what fixed it because I freshly installed 22.1. before I allowed ICMPv6 echo requests on LAN and WAN interface.
Some ICMPv6 was allowed by default, but obviously echo requests were not included.

[skywalker007]

Hmm. How would explain why it only happens occasionally and only when the line breaks? Again, reloading the PPPoE  interface or restarting everything in order ( modem first, line up, then firewall) will establish a proper Connection and I get IPv6 on all VLANs via track interface.
Till

[tiermutter]

I am not very firm with how all this works and can't explain it. As said, maybe the fresh install fixed it for me.
Even if I don't have PPPoE, saving the interfaces without changes brought v6 back. The issue only happened when WAN interface was down or sometimes after a reboot.

Just give it a try and create a pass rule for WAN (and LAN) IPv6-ICMP, Echo service request.

[skywalker007]

Ok thanks. I'll give it a try.

[skywalker007]

This is what I have in terms of ICMP6 on WAN.
Is that sufficient?

[tiermutter]

I've got only the defaults (IPv6 RFC4890 requirements (ICMP)) and additionally ICMPv6 echo service requests...

[bartjsmit]

Any reason not to allow all ICMPv6? The IPv4 old warning was that you don't want miscreants to scope out your internal network by pinging all addresses. The vast size of IPv6 address spaces has made that a moot point.

Bart...

[skywalker007]

I've got only the defaults (IPv6 RFC4890 requirements (ICMP)) and additionally ICMPv6 echo service requests...

Is there any quick way of applying RFC4890 compliant rules I missed? Like a predefined set of rules or a parameter?

[tiermutter]

The rules should be autogenerated in floating section, aren't they?
At this moment I don't know where the rules come from...

[skywalker007]

The rules should be autogenerated in floating section, aren't they?
At this moment I don't know where the rules come from...

Indeed they are, forgive my blindness. Was looking in WAN only.

[skywalker007]

But in that case I am well covered with IPv6ICMP and that is obviously not the reason for my problem

[skyeci2018]

Hi Till

I have the exact same problem as you which has been going on for some time.
My setup is with zen, ppoe (fttp connection).
If the wan interface goes down or I simulate a wan failure (e.g pull the lead) when the connection is restored opnsense does not pick up the ipv6 again. I usually reboot the box to resolve it.

Seems very odd opnsense won't pick up the address.

[marjohn56]

It's a case of debugging dhcp6c to see what is and what is not happening. Set the log level for dhcp6c to debug, pull the WAN cable, wait a few seconds and reconnect. Look at the log file and filter for dhcp6c to see what events took place. You should see dhcp6c sending solicits and a response ( or two ) from the ISP BNG.


Is that happening?


N.B. After changing the log level you'll need to reboot before doing the test.