Recent posts

#1
26.7, 26.10 Series / Re: [SOLVED] A bug in 26.7.9_1...
Last post by Greelan - November 13, 2026, 11:40:53 PM
Yes, it is normal since those files are the ones changed in the patch.

You can expect the patch to be cherry-picked into 26.7.10.
#2
26.7, 26.10 Series / Re: [SOLVED] A bug in 26.7.9_1...
Last post by lmoore - November 13, 2026, 11:10:39 PM
Deleted.
#3
Tutorials and FAQs / Re: [HOWTO] Configure WAN MTU ...
Last post by meyergru - November 13, 2026, 10:33:42 PM
Did you reboot? As mentioned, the order of interface initialisation matters and the results upon initial configuration may be different.

I am with the exact same ISP and do not see your results with http://pmtud.enslaves.us/. My setup is shown above, and I get the same effective MTUs as you with the pings but then:

QuotePath MTU Discovery Test
Results
Direction   Tested Maximum Size Segment   Client Sent MSS   Notes
Server to Client IPv4   1460 (MTU 1500)   1460 (MTU 1500)   OK
Client to Server IPv4   unlimited   (n/a)   OK
Server to Client IPv6   1440 (MTU 1500)   1440 (MTU 1500)   OK
Client to Server IPv6   unlimited   (n/a)   OK
got server to client probe for mss 536 (max seg 1460)
got server to client probe for mss 1460 (max seg 1460)
got server to client probe for mss 1460 (max seg 1460)
finished s2c4 probing, maximum mss 1460 peer mss 1460 initial peer mss 1460
got client to server probe for mss 520
got client to server probe for mss 1461
got client to server probe for mss 9000
finished c2s4 probing, maximum mss 9000
got server to client probe for mss 536 (max seg 1440)
got server to client probe for mss 1440 (max seg 1440)
got server to client probe for mss 1440 (max seg 1440)
finished s2c6 probing, maximum mss 1440 peer mss 1440 initial peer mss 1440
got client to server probe for mss 520
got client to server probe for mss 1441
got client to server probe for mss 9000
finished c2s6 probing, maximum mss 9000


You could also look into "grep -n 'max-mss' /tmp/rules.debug" and see if there is any rule that limits your TCP MSS to 1452.

Contrary to the instructions one difference might be that I set MSS 1500 on pppoe0 explicitely - although it should not be the culprit, you may want to try it.


#4
General Discussion / Any plan to support 4G umb (MB...
Last post by Oulra - November 13, 2026, 10:32:32 PM
Hello everyone,

I've been using a 4G PPP connection with an EM7565 modem for several years now, and FreeBSD 15 now supports the use of the umb driver for MBIM interfacing.

I just tried it manually by playing around with umbctl, and it's pretty simple to set up. I lose the ability to have automatic outbound NAT rules, but other than that, the connection is night and day! I've more than doubled my download and upload speeds, and the latency has improved dramatically.

So I'm pretty excited about the idea of being able to use it properly, and I'm wondering if there are plans to support this natively within the OPNsense core in the future?

Here's some info for anyone interested in switching my EM7565 to MBIM mode:

cu -l /dev/cuaU0.0
AT!ENTERCND="A710"
AT!USBCOMP=1,1,100D

Load the umb driver by adding umb_load="YES" to /boot/loader.conf.local and reboot.

After rebooting, verify that the umb0 interface appears, then configure the APN number, PIN, and enable roaming by creating a file umb.conf:

apn=Free
pin=0000
roaming

Initiate the connection:

umbctl -f umb.conf umb0
All that's left is to assign your interface to umb0 (IPv4 None), add the gateway manually, add NAT rules and you're good to go!
#5
26.7, 26.10 Series / Re: [Solved] UPNP fatal error ...
Last post by Component0002 - November 13, 2026, 10:23:17 PM
I'm getting the exact same issue as axsdenied after updating:

ErrorminiupnpdSTUN server not supported, not returning OTHER-ADDRESS / support CHANGE-REQUEST's required for endpoint-independent (1:1) CGNAT filtering tests per RFC 5780.

This seems to be unique to stun.l.google.com as if I change it to stun.3cx.com it starts correctly.

Should we open a bug report for this somewhere?
#6
Portuguese - Português / Re: Sem acesso ao site de cons...
Last post by mamebill2 - November 13, 2026, 09:39:38 PM
A sugestão de utilizar Sticky Connections faz bastante sentido em ambientes com Multi-WAN, pois manter a mesma conexão pela mesma interface pode evitar problemas de autenticação e interrupções durante o acesso a determinados portais. Também vale testar uma regra de Policy Routing específica para o domínio da Receita, acompanhando os logs para identificar o resultado.


Para quem gosta de jogos clássicos no computador, gta san andreas notebook é uma busca interessante para encontrar informações sobre instalação e compatibilidade. Antes de instalar, vale conferir os requisitos de hardware, memória e sistema operacional para garantir que o jogo funcione adequadamente no notebook.
#7
26.7, 26.10 Series / Re: [CALL FOR TESTING] DHCP re...
Last post by OPNenthu - November 13, 2026, 09:11:06 PM
It's running here now, too.  Came up fine on reboot.
#8
Tutorials and FAQs / Re: [HOWTO] Configure WAN MTU ...
Last post by abulafia - November 13, 2026, 09:03:55 PM
M-Net Fiber in Munich.
igb0 set to mtu 1512
VLAN 40 set to mtu 1508
PPPoE set to mtu 1500 (in advanced settings)
WAN no mtu set.

ifconfig shows
igb0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1512
vlan0.40: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1508
pppoe0: flags=1008ad1<UP,POINTOPOINT,RUNNING,NOARP,ALLMULTI,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500

OPNsense passes pings with MTU 1500:
@OPNsense:~ % sudo ping -D -s 1472 8.8.8.8
Password:
PING 8.8.8.8 (8.8.8.8): 1472 data bytes
1480 bytes from 8.8.8.8: icmp_seq=0 ttl=120 time=4.469 ms
1480 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=5.022 ms

A Debian machine passes pings with MTU 1500:
$ ping -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
1480 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=8.17 ms
1480 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=5.31 ms

Windows passes pings with MTU 1500:
ping 1.1.1.1 -f -l 1472
Ping wird ausgeführt für 1.1.1.1 mit 1472 Bytes Daten:
Antwort von 1.1.1.1: Bytes=1472 Zeit=4ms TTL=59
Antwort von 1.1.1.1: Bytes=1472 Zeit=4ms TTL=59

HOWEVER, OPNsense still shows a calculated MTU of 1492 in the "WAN" interface section, and http://pmtud.enslaves.us/ shows a mtu of 1492 only as well:

QuotePath MTU Discovery Test
Results
Direction    Tested Maximum Size Segment    Client Sent MSS    Notes
Server to Client IPv4    1452 (MTU 1492)    1452 (MTU 1492)    OK
Client to Server IPv4    unlimited    (n/a)    OK
got server to client probe for mss 536 (max seg 1452)
got server to client probe for mss 1452 (max seg 1452)
got server to client probe for mss 1452 (max seg 1452)
finished s2c4 probing, maximum mss 1452 peer mss 1452 initial peer mss 1452
got client to server probe for mss 400
got client to server probe for mss 1453
got client to server probe for mss 9000
finished c2s4 probing, maximum mss 9000
#9
Hardware and Performance / Re: N150 Mini PC, RTL8153, AX8...
Last post by nero355 - November 13, 2026, 08:54:59 PM
Quote from: dogshome on November 13, 2026, 05:46:29 PMa CAT8 cable from one side of the house to the other. This has given good gains with my NAS as expected.
You don't need anything better than CAT6a cabling for 10 Gbps up to 100 meters with RJ45 connectors ;)
#10
26.7, 26.10 Series / Re: Gradual Internet Performan...
Last post by tonys - November 13, 2026, 08:36:39 PM
Quote from: tonys on November 10, 2026, 10:56:45 PM[...]At this point, I'm wondering why the state table grows so large[...]

QuoteWhat protocol/service? TCP sessions tend to hang around; I usually have a bunch of TCP DNS sessions in TIME_WAIT, as DNS can be a spew. My old Fortigate had granular control of session timeouts, one of its few advantages. Not a functional issue, really - I mostly cut UDP DNS timeouts to reduce clutter when browsing the state table. I don't bother with OPNsense.

As of this morning, all of the _WAIT states are TCP. It's not too bad, 76 wait states out of about 960 total states. However, and this is an ongoing issue, I still can't access some web sites (including this board) without turning on the external VPN. Kind of a pain... almost all of the TIME_WAIT connections are going out to either http (80) or https (443) - only two are going to quad9 DNS (853).

QuoteI'd expect sessions to be more of a memory issue than processor, and I wouldn't expect a problem with 16GB. Those session spikes may be more of a symptom than a cause - the protocol may be revealing. (I have static IPs and servers; I average a few hundred sessions, lots of bots/scrapers/whatever can put that up to 5000 or so for hours or days. That doesn't even account for the constant stream of blocked packets.)

I run an external OpenVPN server on a raspberry pi 5. The incoming bot packets are enormous and most of them are targeting VNC on port 5900, etc. There's no VNC port open but that doesn't stop them.

I upgraded to 26.7.9_1 this morning... hmmm...