Hello,
after upgrading OPNsense from 26.7.2_2 to 26.7.3, my PPPoE WAN connection stopped working completely. Restoring the Proxmox snapshot containing OPNsense 26.7.2_2 immediately restored the connection without any other configuration or network changes.
Environment
- OPNsense running as a virtual machine on Proxmox
- OPNsense 26.7.2_2: working
- OPNsense 26.7.3 or possibly 26.7.3_1: not working
- The exact hotfix revision is unfortunately unknown
- The WAN connection is passed to the VM through Proxmox bridge `vmbr0`
- The optical termination device is a Luleey 2.5G XPON Stick SFP ONU
- The stick is connected to a UniFi switch
Network topology
The connection is approximately:
Luleey XPON stick → UniFi switch → VLAN 10 → Proxmox vmbr0 → OPNsense VLAN 10 → PPPoE → WAN
VLAN 10 is both:
- the transport VLAN between the UniFi switch and OPNsense, and
- the VLAN required for the provider's PPPoE service.
Inside OPNsense, VLAN 10 is created on the interface connected to `vmbr0`. The PPPoE device uses this VLAN device as its link interface. The VLAN 10 interface itself is not assigned as a separate OPNsense interface; only the resulting PPPoE device is assigned as WAN.
A separate native VLAN is present on the switch port for access to the management interface of the XPON stick. This management VLAN remained unchanged and should not be involved in the PPPoE connection.
Actual behaviour with 26.7.3
After installing the update and rebooting:
- the PPPoE connection remained completely offline;
- no WAN connection was established;
- the VLAN 10 device was still used as an unassigned interface underneath the PPPoE device;
- additional reboots did not restore the connection.
No changes were made to the OPNsense configuration, Proxmox networking, UniFi switch configuration or XPON stick configuration.
Unfortunately, I did not save the PPP logs before restoring the snapshot because I needed to restore Internet access.
Rollback result
I restored the complete Proxmox snapshot containing OPNsense 26.7.2_2. The PPPoE WAN connection came back immediately without changing or rebooting the UniFi switch, XPON stick or any other part of the network.
This makes the issue appear specific to the update from 26.7.2_2 to 26.7.3.
The 26.7.3 changelog includes the interface-related change "resolve VLAN devices indirectly via interfaces_configure()". Could this affect PPPoE devices that use an otherwise unassigned VLAN device as their link interface?
best regards
Downset
https://github.com/opnsense/core/issues/10806
Thanks for the hint to the git issue.
The patch just released there is fixing the problem.
Thanks for the fast support
best regards
Hotfixed in 26.7.3_2.
Thanks for the quick fix! Had the same issue, luckily was able to recover by disabling and re-enabling the WAN / PPPoE interface after reboot.
Hi,
I have a very similar problem and hope it's ok to reply to this topic, otherwise I can also open a new one.
So when on 26.7.1 my PPPoE config works fine and the connection comes up. I get an IP from the ISP etc and there is no problem as far as I can see.
But if I'm upgrading to 26.7.5 (I also tried to upgrade to 26.7.4 and 26.7.4_1 before multiple times) the PPPoE always fails. The interfaces are up and if I check the Interface Overview/assignments/etc. everything looks the same for me but I don't get a public IP and the status of the WAN interface on the Dashboard is active but "undefined".
I did some research with AI (in fact Claude, ChatGPT and Gemini) and after I tried all the suggested workarounds the AI always comes to the conclusion this must be a bug.
I'm not sure if this is really true because you know AI always sounds pretty sure about everything but isn't always right and after some research I also read a lot about most problems are more config errors than bugs so I guess this is maybe more my problem.
So from the log I can see that the PPPoE just doesn't work, but I'm not sure why. If I do a diff between 26.7.1 log and 26.7.5 log I can see the order of the log messages regarding the WAN interface and PPPoE is a little different but everything happens at the same second. For the AI this is the root cause as the order has to be different and this is a key problem for my config. But as I already mentioned I'm not really sure about this.
Another potential problem according to the AI is that I have 2 10G interfaces for internal traffic and the WAN interface is only a 1G interface. The AI tells me this is a big problem as the 10G interfaces are seen as priority interfaces and the OPNSense tries to connect via those interfaces instead of the 10G which then fails. But I can't see any hint of that in the log files.
I tried to follow the How To Guide about PPPoE over VLAN but it's already 5 years old and I'm not sure if this is still correct after all those years.
Maybe someone can help me, because I now spent so many hours on that problem that I don't know what options are left to solve this issue.
Many thanks in advance.
Not sure why it considers pppoe0 down/unable to come up, but it's probably hidden somewhere in your setup.
Can you share this from 26.7.5?
# pluginctl -Q
Thanks,
Franco
Hello Franco,
I uploaded the old and the new output of this command.
Hope this helps.
Regards,
Fanski
Hmm, I'm assuming your WAN sits on top of igb0? As far as timings go it seems to be down/up during the course of the initial WAN configuration which is suboptimal for PPPoE.
Can you try to add igb0 to a new interface and simply enable it without doing any other settings? Then try a reboot and see if the problem persists.
Cheers,
Franco
Could actually be a driver bug similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
Because when the VLAN is added it takes down the parent interface, which makes mpd5 dail in vain and then apparently needs a kick to proceed.
<13>1 2026-10-03T10:42:50+02:00 fw-KG.XYZ kernel - - [meta sequenceId="226"] <6>[26] igb0: link state changed to DOWN
<13>1 2026-10-03T10:42:50+02:00 fw-KG.XYZ kernel - - [meta sequenceId="227"] <6>[26] vlan7: changing name to 'vlan0.35'
It's not very easy to work around this in userspace.
Cheers,
Franco
Okay I think I know what's going on... can you try to set "VLAN Hardware Filtering" on Interfaces: Settings to "Leave default" and reboot.
The down/up for igb0 and igb1 are in your .1 log as well, just not as annoying to the boot sequence as on .5. So we're looking for kernel behaviour instead of anything we've done directly.
Cheers,
Franco
Hi Franco,
Quote from: franco on October 06, 2026, 11:15:17 AMHmm, I'm assuming your WAN sits on top of igb0?
so yes the ONT is connected to igb0.
Quote from: franco on October 06, 2026, 11:48:51 AMcan you try to set "VLAN Hardware Filtering" on Interfaces: Settings to "Leave default" and reboot.
did that and unfortunately it didn't solve the issue. still the same behavior. I also tested it with 26.7.1 and at first everything was working except the internet traffic because of state violations, but after playing with the 3 different options and 3 or 4 reboots it worked without a problem and also after some reboots.
Quote from: franco on October 06, 2026, 11:15:17 AMCan you try to add igb0 to a new interface and simply enable it without doing any other settings? Then try a reboot and see if the problem persists.
I think I already tried this before once or twice as it was a suggested workaround, but I tried again and also with the VLAN Hardware Filtering disabled or leave default but this also had no positive effect.
I attached the logs with the VLAN Hardware Filtering default option, and the ones with the dummy interface.
Regards,
Fanski
Thanks for testing... looks like we need a bigger hammer:
# opnsense-patch https://github.com/opnsense/core/commit/3384e551f3
I think I want to take this further, but this should address your issue given that the 10 seconds are enough to bring the interface up. I counted 5 seconds which is pretty slow already.
Cheers,
Franco
Hi Franco,
unfortunately it seems the hammer was not big enough?!
The problem still exists after upgrading to 26.7.6_3 and with the patch installed.
Or should I have only upgraded to 26.7.5?
Regards,
Fanski
Did you install the patch and then upgrade to _3? It looks like the patch is not active which would explain it not working.
After doing a firmware upgrade patches are undone.
Cheers,
Franco
No I did it in that order:
1. download the patch with opnsense-patch -d 3384e551f3
2. copied the patch to /root/3384e551f3.patch
3. checked if the patch is working with patch -d /usr/local -p2 --dry-run < /root/3384e551f3.patch
4. upgraded to 26.7.6_3
5. PPPoE was not working so i used this command patch -d /usr/local -p2 < /root/3384e551f3.patch
6. did a reboot
7. PPPoE was still not working so I checked /usr/local/etc/inc/interfaces.inc if the lines written in the patch are in there. They were there so I guessed the patch was working
8. did a second reboot and reloaded the ONT to be sure it's not another problem, but that didn't help
Maybe I did something wrong or need to activate something additionally?
But back in 26.7.1 the lines aren't in the interfaces.inc anymore so I'm pretty sure it was at least updated.
Is there something else I can check if to see if the patch is correctly installed?
Regards,
Fanski
Hi Franski,
Okay, just wanted to double check. Let me try to come up with debug output for your case. The patch not working would indicate the VLAN is up when it is supposed to wait for it to come up... which is silly because it will be down a split second later? It's not easy to work around this when the kernel lives on its own schedule.
Maybe you can try to increase the sleep to 5 seconds in order to catch the down window?
Cheers,
Franco
Hi Franco,
so I tried with 5, 10 and 15 seconds but no success.
I changed this (log message was just for me to be sure where this happens and if it works :) ):
/* wait for functional parent (only the first) */
$max = 10;
$i = 0;
while ($i < $max) {
sleep(15);
log_msg("sleeping", LOG_WARNING);
if (does_interface_exist($ports[0], 'up')) {
break;
}
$i++;
}
I'm just curious, do you think this could be hardware related? I use an old firewall for my setup. It was for free so for my home config it was good enough.I thought maybe the old hardware is not working properly with the new firmware/something in the modern architecture is causing this issue with my old hardware.
Regards,
Fanski
That means the VLAN us up while the parent is down, which is even more inconvenient. Yes, this is definitely a driver issue.
I added
https://github.com/opnsense/core/commit/d2ad94b38b48
and
https://github.com/opnsense/core/commit/212185a8be
which tries to look at the up state of the parent, not the port itself. Your case at least already proves that this is likely not waiting for anything in most cases, but it might fix the issue you're seeing now.
If not there's a problem with the lookup, a) not waiting for the right device which would be my fault or b) the kernel driver for igb takes it down after we pass the wait test (worst case).
If you have trouble applying these patches I can try to make a proper backport for 26.7.6_3.
Cheers,
Franco
PS: I've were honing in on "igb" being the culprit we can easily limit the wait code to that interface name to minimize impact for others.
Hi Franco,
still not coming up :(
So I upgraded again to 26.7.6_3, installed patch 3384e551f3 and reboot, then patch d2ad94b38b48 and reboot and then patch 212185a8be and reboot but unfortunately it's still the same behavior.
Maybe just a short question:
In 26.7.1 the vlan0.35 was not the first VLAN to be created. In the following versions it is always is the first one/vlan0, all the other VLANs created later seem to work without a problem. Is there a possibility switch the order again (maybe it's just the first one which is created which has problems)? Or is this a mandatory behavior that the VLAN attached to the WAN interface always needs to be the first to be created?
Regards,
Fanski