Problems after enabling if_pppoe

bigsy

Hi

Netgate 5100 (8GB RAM, 120GB m.2SATA)
Additional packages: pfB NG, WireGuard, Tailscale, ACME

WAN is on a 900/100 PPPoE connection (Zen UK)
IPv4 (/29) and IPv6 enabled and working

Upgraded successfully from pfSense+ 24.11 to 25.03 beta (Tue Apr 29 14:29:00 BST 2025)
I noticed that the new if_pppoe was not enabled by default.

As I wanted to try this out, I enabled this option and rebooted the appliance.

After reboot completed I was no longer able to access the pfSense webgui - the login page gives a 50x Error and the message "The webserver encountered an error processing this request. Check the Crash Reporter for details"

The link to the Crash Reporter does not work.

The system.log is filled with the message

check_reload_status[685]: Could not connect to /var/run/php-fpm.socket

I successfully reverted to Plus 24.11 via BE.

I'm not sure where to look to troubleshoot this further. I have all the logs from this upgrade if that helps.

Thanks

patient0

@bigsy if_pppoe shouldn't have any impact on the WebGUI access.

If you upgrade to 25.03-BETA and not enable if_pppoe, does all work as before?

bigsy

@patient0 Yes.

patient0

@bigsy that's a new one then.

Can you still access pfSense using SSH/console and restart the WebGui (menu entry 11) and or restart php-fm (menu entry 16)?

bigsy

@patient0 Thanks for the replies. I've been switching between boot environments to test things.

I have both console and SSH access. Menu options 11/16 didn't help.

I then realised that there was no DNS resolution at the CLI, so I manually restarted unbound and then menu option 16 brought the webgui back up.

It appears to be working now. I'll keep it running to see if there are any more problems.

Gertjan

@bigsy said in Problems after enabling if_pppoe:

I then realised that there was no DNS resolution at the CLI,

Check the resolver log ( and system log ) if you can find a reason why the resolver didn't start.
/var/log/resolver.log and /var/log/system.log.

bigsy

@Gertjan system.log during boot up has a lot of messages along the lines of:

May  6 14:27:56 bru php-fpm[16386]: /rc.newwanip: Unbound start waiting on dhcp6c.

and

May  6 14:27:57 bru php-fpm[8553]: /rc.newwanip: Netgate pfSense Plus package system has detected an IP change or dynamic WAN reconnection - 82.x.y.z ->  82.x.y.z - Restarting packages.
May  6 14:27:57 bru check_reload_status[685]: Starting packages
May  6 14:27:57 bru php[53534]: /usr/local/sbin/ppp-ipv6: Accept router advertisements on interface pppoe0 
May  6 14:27:57 bru php[53534]: /usr/local/sbin/ppp-ipv6: Starting rtsold process on wan(pppoe0)
May  6 14:27:57 bru php-fpm[8553]: /rc.newwanip: rc.newwanip: Info: starting on pppoe0.
May  6 14:27:57 bru php-fpm[8553]: /rc.newwanip: rc.newwanip: on (IP address: 82.x.y.z) (interface: WAN[wan]) (real interface: pppoe0).
May  6 14:27:57 bru check_reload_status[685]: rc.newwanip starting pppoe0
May  6 14:27:57 bru php-fpm[91042]: /rc.newwanip: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1746538077] unbound[68242:0] error: bind: address already in use [1746538077] unbound[68242:0] fatal error: could not open ports' 
May  6 14:27:57 bru php-fpm[30102]: /rc.newwanip: Forcefully reloading IPsec
May  6 14:27:57 bru php[82727]: /usr/local/sbin/ppp-ipv6: Starting rtsold process on wan(pppoe0)
May  6 14:27:57 bru php[73254]: /usr/local/sbin/ppp-ipv6: Accept router advertisements on interface pppoe0 
May  6 14:27:57 bru php[73254]: /usr/local/sbin/ppp-ipv6: Starting rtsold process on wan(pppoe0)
May  6 14:27:57 bru php-fpm[16386]: /rc.newwanip: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1746538077] unbound[88722:0] error: bind: address already in use [1746538077] unbound[88722:0] fatal error: could not open ports' 
May  6 14:27:57 bru php-fpm[30102]: /rc.newwanip: Resyncing OpenVPN instances for interface WAN.
May  6 14:27:57 bru php-fpm[30102]: OpenVPN terminate old pid: 37576
May  6 14:27:58 bru kernel: ovpns1: link state changed to DOWN
May  6 14:27:58 bru check_reload_status[685]: rc.newwanip starting pppoe0

(WAN IP address masked)

stephenw10

Looks like it's looping. Do you have Do not wait for a RA set in the dhcpv6 settings?

Try unchecking that. If that allows it to connect normally that's a known issue that should be fixed in the next public build.

bigsy

@stephenw10 Thanks. 'Do not wait for a RA' is NOT checked in the DHCP6 client configuration.

stephenw10

Hmm, interesting. Do you see the connection logs repeating? Like it's continually re-connecting?

bigsy

@stephenw10 said in Problems after enabling if_pppoe:

Hmm, interesting. Do you see the connection logs repeating? Like it's continually re-connecting?

No, the connection seems to establish and stay up.

stephenw10

Hmm, but the logs are still filling continually?

w0w

@stephenw10
Sorry, but I'd like to correct you that "Do not wait for RA" should be checked to bypass this issue.

stephenw10

It depends which issue. If your ISP sends a lot of RAs you probably want it checked. If not then leaving it unchecked can avoid a race condition.

Both should be fixed in the next build.

bigsy

@stephenw10 said in Problems after enabling if_pppoe:

Hmm, but the logs are still filling continually?

No. The logs fill with those messages on rebooting after enabling if_pppoe and also on each subsequent reboot.

This stops once I restart unbound via the cli and then use menu options 11/16 in order to be able to access the webgui. Once that is done the continuous log messages stop.

bigsy

@stephenw10 Same problem here with the new 25.03-BETA (amd64) built on Wed May 7 17:11:00 BST 2025

marcosm

@bigsy Does applying this patch help?
https://github.com/pfsense/pfsense/commit/e4f3b5ced884dd0bece804a296191f6a1746643c.diff

bigsy

@marcosm said in Problems after enabling if_pppoe:

https://github.com/pfsense/pfsense/commit/e4f3b5ced884dd0bece804a296191f6a1746643c.diff

Thanks. Afraid it didn't help - I applied the patch, rebooted and the same behaviour was exhibited.

bigsy

I'm still experiencing the same problems as originally described on the latest 25.03-BETA (amd64)
built on Thu May 15 15:15:00 BST 2025 whenever if_pppoe is enabled and the system rebooted.
No problems when if_pppoe is not used.

stephenw10

Hmm, do you have a more complete log of what you're seeing?

If you set 'Do not wait for RA' does the behaviour change?