Recent posts

#1

26.1, 26,4 Series / Re: PHP2Shell security fix for...

Last post by weilander - Today at 06:55:04 PM

Hi Franco,

I understand your point, and I don't disagree with the technical advice. In fact, newsense's recommendation made me reconsider my approach, and as you can see, I ultimately followed it. I also appreciate the work you put into providing the PHP security update for 26.1.

But I do think there's a difference between giving the right advice and the way that advice is delivered.

I came here with a genuine question, asked politely, and explained why I was hesitant to rush a major upgrade on a production firewall. I wasn't questioning the importance of security updates or expecting unsupported versions to be maintained indefinitely.

Being told that I had "far bigger issues than a couple php vulnerabilities" and that there was "no reason to wait for miracles" felt unnecessarily dismissive. The same technical advice could have been given clearly and firmly without those remarks.

I wouldn't have chosen tracker's rather harsh wording either. But I do think he has a point about how people communicate with each other in technical forums.

Being technically right and treating someone respectfully are not mutually exclusive. Especially when someone comes here looking for help.

I'm grateful for the advice and support I received, and the successful upgrade speaks for itself. I just think the tone matters, too.

Cheers,
Michael

#2

Development and Code Review / Re: Freeradius VLAN fallback c...

Last post by franco - Today at 06:11:43 PM

Hi Claudio,

I asked Michael for comment.


Thanks,
Franco

#3

Development and Code Review / Re: Ports build error fetching...

Last post by franco - Today at 06:10:33 PM

https://github.com/opnsense/ports/issues/305

#4

26.1, 26,4 Series / Re: PHP2Shell security fix for...

Last post by franco - Today at 05:59:37 PM

On the other hand, user newsense can piss right off with this attitude... if you don't have a solution, just don't say anything instead of compounding on an already stressful issue with this passive-aggressive nonsense.

I think this is uncalled for and actually wrong at the same time.  He gave the best advice to move forward.  Everything else is running old versions on borrowed time.

11 years ago a lot of people said we're crazy with our update approach. Now in 2026, skip a week's worth of security work and you're already behind. It's been a strange journey.

Cheers,
Franco

#5

German - Deutsch / Re: Upgrade 26.7.5 > 26.7.6 od...

Last post by viragomann - Today at 05:25:44 PM

Hallo.

Sobald das Update fehlerfrei durchlief, ist die Firewall nicht mal mehr per Ping aus einem meiner VLANS erreichbar.

Hast du auch eine Neuinstallation und eine anschließende Wiederherstellung der Konfiguration versucht?

Auf der Konsole kann ich ebenso Teilnehmer von der OPNsense anpingen, auch aus anderen VLANs. Netzwerkverbindung steht also. Nicht mehr erreichbar ist offensichtlich alles von außen IN die opnsense.

Also Verbindungen durch die OPNsense funktionieren, der Zugriff auf sie selbst aber nicht?
Da würde ich vermuten, dass dieser aus irgendeinem Grund blockiert wird. Was es ist, sollte das FW Log zeigen, vorausgesetzt, Logging ist aktiviert.

Die Firewall kannst du in der Konsole deaktivieren:
pfctl -d
Dann solltest du auf die Web GUI kommen und das Problem vielleicht ausfindig machen können.

Falls es nicht offensichtlich ist, musst du Untersuchungen anstellen. Dazu wenn nicht eh aktiv, dann das Logging aller relevanten Regeln wie auch das der Default Block Rule (Firewall: Settings: Advanced > Default block) aktivieren.
Dann kannst du die FW wieder aktivieren:
pfctl -e
und ein paar Zugriffsversuche unternehmen, die blockiert werden. Danach die FW wieder deaktivieren und in der GUI die Logs prüfen. Die Ursache sollte sich so hoffentlich zeigen.

#6

26.7 Series / ixv virtual function interface...

Last post by Hendre - Today at 04:40:04 PM

Hi everyone,

I'm having an issue with Intel X540 SR-IOV virtual functions ("ixv") on OPNsense 26.7 / FreeBSD 15.1 running under VMware ESXi 8.

The VF appears to receive and transmit traffic, according to ESXi statistics, but VLAN communication isn't working. I've also tested creating a VLAN interface ("ixv2.20") directly in OPNsense.

I suspect outgoing traffic isn't being VLAN-tagged correctly, although I haven't confirmed this with a packet capture. Switching back to VMXNET3 works.

Has anyone encountered this with "ixv" since the FreeBSD 15 upgrade? Could this be related to the recent Intel driver changes, or is there a known workaround?

Please help, my previous post didn't get any response.

#7

26.7 Series / Re: PPPoE over an unassigned V...

Last post by GOJ - Today at 04:17:20 PM

I'm currently running version 26.7.7 and I'm experiencing the same issue with PPPoE.
It looks like something is broken in LCP/PAP (ppp[72477]: [wan_link0] LCP: auth: peer wants PAP, I want nothing).

Log messages as follows:
--------------------------
[wan_link0] PPPoE: connection successful
ppp[72477]: [wan_link0] Link: UP event
ppp[72477]: [wan_link0] LCP: Up event
ppp[72477]: [wan_link0] LCP: state change Starting --> Req-Sent
ppp[72477]: [wan_link0] LCP: SendConfigReq #45
ppp[72477]: [wan_link0]   PROTOCOMP
ppp[72477]: [wan_link0]   MRU 1492
ppp[72477]: [wan_link0]   MAGICNUM 0x752bf188
ppp[72477]: [wan_link0] LCP: rec'd Configure Request #198 (Req-Sent)
ppp[72477]: [wan_link0]   MRU 1492
ppp[72477]: [wan_link0]   AUTHPROTO PAP
ppp[72477]: [wan_link0]   MAGICNUM 0x7363e98b
ppp[72477]: [wan_link0] LCP: SendConfigAck #198
ppp[72477]: [wan_link0]   MRU 1492
ppp[72477]: [wan_link0]   AUTHPROTO PAP
ppp[72477]: [wan_link0]   MAGICNUM 0x7363e98b
ppp[72477]: [wan_link0] LCP: state change Req-Sent --> Ack-Sent
ppp[72477]: [wan_link0] LCP: rec'd Configure Ack #45 (Ack-Sent)
ppp[72477]: [wan_link0]   PROTOCOMP
ppp[72477]: [wan_link0]   MRU 1492
ppp[72477]: [wan_link0]   MAGICNUM 0x752bf188
ppp[72477]: [wan_link0] LCP: state change Ack-Sent --> Opened
ppp[72477]: [wan_link0] LCP: auth: peer wants PAP, I want nothing
ppp[72477]: [wan_link0] PAP: using authname "xxxxxxxx" (REMOVED)
ppp[72477]: [wan_link0] PAP: sending REQUEST #1 len: 22
ppp[72477]: [wan_link0] LCP: LayerUp
ppp[72477]: [wan_link0] PAP: rec'd NAK #1 len: 18
ppp[72477]: [wan_link0]   MESG: Access Denied
ppp[72477]: [wan_link0] LCP: authorization failed
ppp[72477]: [wan_link0] LCP: parameter negotiation failed
ppp[72477]: [wan_link0] LCP: state change Opened --> Stopping
ppp[72477]: [wan_link0] LCP: SendTerminateReq #46
ppp[72477]: [wan_link0] LCP: LayerDown
ppp[72477]: [wan_link0] LCP: rec'd Terminate Request #199 (Stopping)
ppp[72477]: [wan_link0] LCP: SendTerminateAck #47
ppp[72477]: [wan_link0] PPPoE: connection closed
ppp[72477]: [wan_link0] Link: DOWN event
ppp[72477]: [wan_link0] LCP: Down event
ppp[72477]: [wan_link0] LCP: state change Stopping --> Starting
ppp[72477]: [wan_link0] Link: reconnection attempt 484 in 1 seconds
ppp[72477]: [wan_link0] Link: reconnection attempt 484
--------------------------

#8

General Discussion / Boot console with Intel AMT/ME...

Last post by trixie7 - Today at 03:25:26 PM

I have been struggling to get the OPNsense serial boot console working with the serial-over-LAN (SOL) capability in the Intel ME. I can verify that the SOL device is working correctly, but the operating system refuses to redirect boot messages over the interface. They always display on the hardware UART (COM1) on 0x3F8. I'm running OPNsense 26.7.7.

Here's what I've done so far. Hoping for some guidance on what to do next. I know it's a long post...

FreeBSD 15.1 did not support the SOL UART on this machine natively, so I had to recompile the kernel to add the following line in /usr/src/sys/dev/uart/uart_bus_pci.c:

Code Select Expand

{ 0x8086, 0xa363, 0xffff, 0, "300/C240 Series Chipset Family Keyboard and Text (KT) Redirection", 0x10 | PCI_NO_MSI }

After doing that, the system assigned "uart2" to the device. Previously, this had a name of "none" and the kernel would not load a driver. dmesg also shows the device loading at boot. This is good, but note how the console is attached to uart0--more on that later.

Code Select Expand

# pciconf -l
...
uart2@pci0:0:22:3:      class=0x070002 rev=0x10 hdr=0x00 vendor=0x8086 device=0xa363 subvendor=0x1028 subdevice=0x0860
...

# dmesg | grep uart
[1] uart2: <300/C240 Series Chipset Family Keyboard and Text (KT) Redirection> port 0x30a0-0x30a7 mem 0x91137000-0x91137fff at device 22.3 on pci0
[1] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
[1] uart0: console (115200,n,8,1)

I configured the console and set some tunables to force the console to use the SOL interface. Note that the IO address correctly references the device address of uart2 (0x30a0). This is all based on guidance from various sources: (1), (2), and (3).

You cannot view this attachment.

You cannot view this attachment.

I also added a flag for uart2 to /boot/device.hints at the recommendation of the uart(4) man page. (Although, I don't think this had any effect because the flag didn't show up in dmesg above for uart2.)

Code Select Expand

hint.uart.2.flags="0x10"

And yet, OPNsense continues to use the physical serial port (0x3F8) to output boot messages and provide serial console access. It does not honor comconsole_port. I see no output on the SOL interface when connected with MeshCommander or amtterm during boot--but it does show up on the physical serial port that I have connected to another system for testing.

Code Select Expand

# kenv | grep comconsole_port
comconsole_port="0x30a0"

# ps aux | grep getty
root   72550   0.0  0.0   14132  2552 u0  Is+  09:36     0:00.00 /usr/libexec/getty 3wire.115200 ttyu0
root   48294   0.0  0.0   14132  2540 v0  Is+  09:05     0:00.00 /usr/libexec/getty Pc ttyv0
root   48571   0.0  0.0   14132  2548 v1  Is+  09:05     0:00.00 /usr/libexec/getty Pc ttyv1
root   48578   0.0  0.0   14132  2544 v2  Is+  09:05     0:00.00 /usr/libexec/getty Pc ttyv2
root   48641   0.0  0.0   14132  2544 v3  Is+  09:05     0:00.00 /usr/libexec/getty Pc ttyv3
root   48739   0.0  0.0   14132  2544 v4  Is+  09:05     0:00.00 /usr/libexec/getty Pc ttyv4
root   48957   0.0  0.0   14132  2544 v5  Is+  09:05     0:00.00 /usr/libexec/getty Pc ttyv5
root   48965   0.0  0.0   14132  2544 v6  Is+  09:05     0:00.00 /usr/libexec/getty Pc ttyv6
root   49239   0.0  0.0   14132  2552 v7  Is+  09:05     0:00.00 /usr/libexec/getty Pc ttyv7
root   20762   0.0  0.0   14088  2616  0  S+   10:12     0:00.00 grep getty

I know the SOL interface is working because I can echo text to /dev/ttyu2 and see it printed in amtterm on a different system. I can also get a full serial console going if I modify /etc/ttys as described here. I have not tried patching the code as suggested in that link, but I also don't think it's necessary because the console is already supposed to be redirected to 0x30a0 and the "onifconsole" flag should work the same way it does for ttyu0 with the standard serial port.

The only setting I haven't been able to change is the one for comconsole_pcidev as discussed in the loader(8) man page. This bug report and this guide provide evidence that comconsole_pcidev=0:22:3 is the correct value to use here--which also matches my system per pciconf above--but I receive an "invalid pcidev" message on bootup when I try that. I haven't been able to figure out how to set this loader tunable.

I'm pretty perplexed at this point. I can't think of anything else to try to force the console to use the SOL interface at boot. There seems to be evidence (on the vanilla FreeBSD side, at least) of this working. Is there something I'm missing? I'd appreciate any help!

#9

High availability / HA: Enter CARP Maintenance mod...

Last post by mossi2000 - Today at 03:09:37 PM

Hi,

i have two opnsense systems running in a simple HA config.
1 ISP Router (FTTH)
two separate connections to the two opnsense devices.
direct HEARTBEAT connection between these.

I upgraded from 26.1.x to 26.7.7 yesterday on both instances.
Then i did some config to move /var/db/rrd and /var/db/ntopng and /var/netflow to tmpfs and for backup via cron.
I found out that most of the config needed to be re-done manually on the backup machine and did not sync via HA.
I definitely had that "enter CARP maintenance" button yesterday...
Now both systems run fine, the CARP Widgets tells Master/Backup and from the Master I can sync to the Backup.
BUT on the Master, the buttons for disabling CARP/entering CARP maintenance mode are gone!
Anything I'm missing?

see attached screenshots

#10

26.7 Series / Re: Will there still be any up...

Last post by mimugmail - Today at 03:07:52 PM

They split the package, currently I dont have the time to port all the changes