"Recent posts
#1
Dutch - Nederlands / Blijvende oplossing 11 reload ...
Last post by raft - Today at 01:49:46 PMBeste community,
Na een recente update van PHP / het systeem op mijn OPNsense-instantie (gedraaid in een gevirtualiseerde lab-omgeving) is de WebGUI onbereikbaar geworden. De core-services en netwerkinterfaces starten vlekkeloos op, maar de webserver kan geen verbinding meer maken met de PHP-backend.
Symptomen & Logboeken
In de logboeken van de WebGUI (/var/log/lighttpd.error.log) verschijnen continu de volgende FastCGI-foutmeldingen:
Plaintext
2026-10-30T17:56:51 Error lighttpd (/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.85/src/gw_backend.c.534) connect() /var/lib/php/tmp/php-fastcgi.socket-0: Connection refused
2026-10-30T17:51:21 Error lighttpd (/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.85/src/gw_backend.c.534) connect() /var/lib/php/tmp/php-fastcgi.socket-4: Connection refused
2026-10-30T13:26:55 Error lighttpd (/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.85/src/gw_backend.c.534) connect() /var/lib/php/tmp/php-fastcgi.socket-1: Connection refused
Ter info: de overige diensten (configd, unbound, routing, dhcp) starten tijdens de boot-sequence allemaal zonder problemen (Notice/Informational) op.
Oorzaak
Het probleem lijkt veroorzaakt te worden door het wegvallen of verlopen van de UNIX domain sockets in /var/lib/php/tmp/ tijdens/na de PHP-update, waardoor lighttpd geen FastCGI-handshake met php-fpm kan voltooien.
Tijdelijke Oplossing (Workaround via Shell)
Ik krijg de WebGUI weer online door via optie 8 (Shell) de configuratiesjablonen opnieuw op te bouwen en de services te herstarten:
Bash
# 1. Map & rechten controleren/aanmaken
mkdir -p /var/lib/php/tmp
chmod 755 /var/lib/php/tmp
# 2. WebGUI sjablonen opnieuw genereren voor de actieve PHP-versie
configctl template reload OPNsense/WebGui
# 3. Services herstarten
service php-fpm restart
service lighttpd restart
Na een recente update van PHP / het systeem op mijn OPNsense-instantie (gedraaid in een gevirtualiseerde lab-omgeving) is de WebGUI onbereikbaar geworden. De core-services en netwerkinterfaces starten vlekkeloos op, maar de webserver kan geen verbinding meer maken met de PHP-backend.
Symptomen & Logboeken
In de logboeken van de WebGUI (/var/log/lighttpd.error.log) verschijnen continu de volgende FastCGI-foutmeldingen:
Plaintext
2026-10-30T17:56:51 Error lighttpd (/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.85/src/gw_backend.c.534) connect() /var/lib/php/tmp/php-fastcgi.socket-0: Connection refused
2026-10-30T17:51:21 Error lighttpd (/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.85/src/gw_backend.c.534) connect() /var/lib/php/tmp/php-fastcgi.socket-4: Connection refused
2026-10-30T13:26:55 Error lighttpd (/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.85/src/gw_backend.c.534) connect() /var/lib/php/tmp/php-fastcgi.socket-1: Connection refused
Ter info: de overige diensten (configd, unbound, routing, dhcp) starten tijdens de boot-sequence allemaal zonder problemen (Notice/Informational) op.
Oorzaak
Het probleem lijkt veroorzaakt te worden door het wegvallen of verlopen van de UNIX domain sockets in /var/lib/php/tmp/ tijdens/na de PHP-update, waardoor lighttpd geen FastCGI-handshake met php-fpm kan voltooien.
Tijdelijke Oplossing (Workaround via Shell)
Ik krijg de WebGUI weer online door via optie 8 (Shell) de configuratiesjablonen opnieuw op te bouwen en de services te herstarten:
Bash
# 1. Map & rechten controleren/aanmaken
mkdir -p /var/lib/php/tmp
chmod 755 /var/lib/php/tmp
# 2. WebGUI sjablonen opnieuw genereren voor de actieve PHP-versie
configctl template reload OPNsense/WebGui
# 3. Services herstarten
service php-fpm restart
service lighttpd restart
#2
General Discussion / Re: nfSensei ( fork pfsense )
Last post by franco - Today at 01:13:53 PM@bob9999 I'm not really understanding where you add more value to this discussion. If your aim was to disrespect some people on this forum (or in this thread) you've likely succeeded.
#3
26.7, 26.10 Series / Re: ixv virtual function inter...
Last post by Hendre - Today at 01:05:58 PMAlready the case in 26.7 and every version from there including 26.7.7_1
#4
German - Deutsch / Re: Frage zu Zertifikaten und ...
Last post by viragomann - Today at 12:43:27 PMHallo,
dann sollte es auch kein Problem aufgrund TLS geben.
Beide Hosts liefern jedenfalls auch eine Antwort. Das Caddy Log zeigt die Upstream-Server IP zu switch2: 192.168.64.8
Ist das in Ordnung?
Hast du es schon mit einem anderen Browser versucht?
dann sollte es auch kein Problem aufgrund TLS geben.
Beide Hosts liefern jedenfalls auch eine Antwort. Das Caddy Log zeigt die Upstream-Server IP zu switch2: 192.168.64.8
Ist das in Ordnung?
Hast du es schon mit einem anderen Browser versucht?
#5
26.7, 26.10 Series / Re: ixv virtual function inter...
Last post by franco - Today at 12:31:03 PMWas this regressing in a particular 26.7.x version or already the case in the initial 26.7?
Cheers,
Franco
Cheers,
Franco
#6
26.7, 26.10 Series / Re: cve-2026-98432 (linux behi...
Last post by meyergru - Today at 11:21:33 AMQuote from: abulafia on <strong>Today</strong> at 10:27:55 AMAlternatively (better?) use a reverse proxy on OPnsense. That definitely terminates the TCP connection at OPnsense, which as a BSD system is not affected by this Linux bug.
...creating new security threats in the process.
#7
26.7, 26.10 Series / Re: cve-2026-98432 (linux behi...
Last post by abulafia - Today at 10:27:55 AMAI recommended to enable "synproxy" state handling for incoming traffic to those Linux servers. The TCP SYN session should then terminate at OPnsense and a clean TCP stream go from OPnsense to the server.
Alternatively (better?) use a reverse proxy on OPnsense. That definitely terminates the TCP connection at OPnsense, which as a BSD system is not affected by this Linux bug.
Alternatively (better?) use a reverse proxy on OPnsense. That definitely terminates the TCP connection at OPnsense, which as a BSD system is not affected by this Linux bug.
#8
26.7, 26.10 Series / Re: cve-2026-98432 (linux behi...
Last post by Monviech (Cedrik) - Today at 10:14:05 AMMaybe open a ticket upstream if you feel like something is missing that you need.
https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Base%20System
But from what I read here its about IP Options, and not TCP options, but maybe I misunderstand something.
https://access.redhat.com/security/vulnerabilities/RHSB-2026-016
Filter Incoming IPv4 Packets Containing IP Options
The following nftables table drops incoming IPv4 TCP packets that contain IP options, which reduces exposure to this vulnerability but cannot fully prevent it. Ordinary application traffic is generally expected to remain unaffected, because standard TCP options are carried in the TCP header and continue to be permitted.
https://bugs.freebsd.org/bugzilla/enter_bug.cgi?product=Base%20System
But from what I read here its about IP Options, and not TCP options, but maybe I misunderstand something.
https://access.redhat.com/security/vulnerabilities/RHSB-2026-016
Filter Incoming IPv4 Packets Containing IP Options
The following nftables table drops incoming IPv4 TCP packets that contain IP options, which reduces exposure to this vulnerability but cannot fully prevent it. Ordinary application traffic is generally expected to remain unaffected, because standard TCP options are carried in the TCP header and continue to be permitted.
#9
26.1, 26.4 Legacy Series / Re: MAC Alias stoped working p...
Last post by franco - Today at 10:14:05 AMHi,
We're not aware of issues with MAC aliases in 26.4.2.
What you can check is whether hostwatch service is interfering with your requirements. Disable service under "Interfaces: Neighbors: Automatic Discovery" to see if the situation changes.
Cheers,
Franco
We're not aware of issues with MAC aliases in 26.4.2.
What you can check is whether hostwatch service is interfering with your requirements. Disable service under "Interfaces: Neighbors: Automatic Discovery" to see if the situation changes.
Cheers,
Franco
#10
26.7, 26.10 Series / [26.10BE] Socket timeouts on h...
Last post by alouw - Today at 10:11:55 AMHi,
Just looking for some pointers to figure out what is going on after upgrading the business edition from 26.4 -> 26.10.
Quickly after upgrading I received issues from my nagios that there were socket timeouts on https related ip addresses (router, firewall haproxy mainly) but even nagios itself fails to load frequently.
checks are IP(v4) based, so DNS should not be in the picture. The checks go over vlans (over the firewall). So vlan30 is checking addresses in vlan10 and the wan vlan.
I can't seem to find any errors in the logging related to timeouts.
Before, on 26.4 all worked perfectly, so it seems to have to do with the upgrade.
Running on a DEC2700.
Any pointers on where to look and tackle this issue ?
Thanks,
Albert
Just looking for some pointers to figure out what is going on after upgrading the business edition from 26.4 -> 26.10.
Quickly after upgrading I received issues from my nagios that there were socket timeouts on https related ip addresses (router, firewall haproxy mainly) but even nagios itself fails to load frequently.
checks are IP(v4) based, so DNS should not be in the picture. The checks go over vlans (over the firewall). So vlan30 is checking addresses in vlan10 and the wan vlan.
I can't seem to find any errors in the logging related to timeouts.
Before, on 26.4 all worked perfectly, so it seems to have to do with the upgrade.
Running on a DEC2700.
Any pointers on where to look and tackle this issue ?
Thanks,
Albert
