After updating to 25.7.1 I have problem with accessing https sites.
There were no changes to WAN/PPPOE conection settings, MTU is set to 1492 and MSS to 1456.
Previously it worked fine, now on windows 10 machine I have to set JumboFrames to 1400 to load Gmail.
Also I have backup connection 5G and when I disable PPPOE it works perfectly fine with MTU of 1500 and MSS 1500 (on windows PC JumboFrames are set to 9000)
I tried disabling normalization (Disable scrub interface) and adding rule in detailed settings added rule with max mtu set to 1456, but it did not work.
As for Path MTU Discovery, all ICMP traffic is enabled on all LAN and WAN interfaces in firewall.
Please let me know if some one has and idea how to fix that or need any more details.
It's working for me, i'm running OPNsense 25.7.1_1-amd64, and confirmed MSS clamping is working.
My LAN PC has MTU = 1500, and a pcaps shows it asks for MSS = 1460 bytes in the tcp syn, and then a pcap run on OPNsense then further confirms the MSS is clamped down to the expected 1452 bytes
Below is my OPNsense config.
Is your config also using PPPoE?
Because it works fine on 5G DHCP connection also for me, but fails on PPPoE
Quote from: Deltorek112 on August 02, 2025, 04:46:15 AMIs your config also using PPPoE?
Sure is, actually i have several PPPoE OPNsense 25.7.1_1 deployments, and all are clearly showing MSS clamping working just fine.
Did you take a look at my screenshot ? you mentioned a MSS 1456 in your original post, which is too large for PPPoE, the largest MSS you'll get, to avoid IP fragmentation is PPPoE MTU/MRU - 40 == 1492 - 40 = 1452....The 40 bytes comes from 20 Bytes for IP header, and 20 bytes of TCP header....the rest is tcp segment payload ( i.e. MSS )
Also you do need to put a valid value in the interface MSS part of the config, if you enter in 1492, OPNsense automatically subtracts the 40 bytes automatically, to give you the perfect MSS 1452 operationally.
Sorry, screenshot was not showing up on phone, set MSS to 1452 and removed MTU and still the same.
Tried ping with size 1466 and it got proper response about it being too big:
ping -f poczta.wp.pl -l 1466
Pinging poczta.wp.pl [193.17.41.249] with 1466 bytes of data:
Packet needs to be fragmented but DF set.
And when I lowered the size to 1464 I got the response:
ping -f poczta.wp.pl -l 1464
Pinging poczta.wp.pl [193.17.41.249] with 1464 bytes of data:
Reply from 193.17.41.249: bytes=1464 time=6ms TTL=60
Reply from 193.17.41.249: bytes=1464 time=5ms TTL=60
All of this was done with MTU empty and MSS set to 1452
But browser is still not able to open Gmail or this site.
Maybe it is a problem with Path MTU Discovery, I run this command:
netsh interface ipv4 show destinationcache
and got this
PMTU Destination Address Next Hop Address
1492 193.17.41.249 192.168.1.1 <--poczta.wp.pl
1492 142.250.186.197 192.168.1.1 <--mail.google.com
But the only change was the upgrade of OPNSense, could firewall filter out the protocol needed for this?
I have floating rules to allow all ICMP traffic.(see screenshot)
Do I need to add any more rules to make it work again?
Also without lowering MTU on windows from 9000 to 1400 I could not attach anything to this post was getting 408
TCP MSS only works for TCP protocol, if your using chrome or brave browser, possibly the browser is using http3/quic protocol which is udp based....
I've never tested OPNsense to see if it supports PMTU discovery before, or if it supports IP fragmentation and re-assembly either, but can test etc....
from the cli, from windows cmd prompt, you should try a curl, something like below, which is tcp port 80 connection
curl -vv http://ifconfig.me
root@OPNsense:~ # curl -v http://ifconfig.me
* Host ifconfig.me:80 was resolved.
* IPv6: 2600:1901:0:b2bd::
* IPv4: 34.160.111.145
* Trying [2600:1901:0:b2bd::]:80...
* Immediate connect fail for 2600:1901:0:b2bd::: No route to host
* Trying 34.160.111.145:80...
* Connected to ifconfig.me (34.160.111.145) port 80
* using HTTP/1.x
> GET / HTTP/1.1
> Host: ifconfig.me
> User-Agent: curl/8.15.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Content-Length: 13
< access-control-allow-origin: *
< content-type: text/plain
< date: Sat, 02 Aug 2025 07:16:36 GMT
< via: 1.1 google
<
* Connection #0 to host ifconfig.me left intact
103.107.16.94root@OPNsense:~ # curl -vv http://ifconfig.me
17:16:44.765112 [0-0] * Host ifconfig.me:80 was resolved.
17:16:44.765273 [0-0] * IPv6: 2600:1901:0:b2bd::
17:16:44.765291 [0-0] * IPv4: 34.160.111.145
17:16:44.765312 [0-0] * [SETUP] added
17:16:44.765345 [0-0] * Trying [2600:1901:0:b2bd::]:80...
17:16:44.765384 [0-0] * Immediate connect fail for 2600:1901:0:b2bd::: No route to host
17:16:44.765412 [0-0] * Trying 34.160.111.145:80...
17:16:44.765490 [0-0] * [SETUP] Curl_conn_connect(block=0) -> 0, done=0
17:16:44.766604 [0-0] * [SETUP] Curl_conn_connect(block=0) -> 0, done=0
17:16:44.792995 [0-0] * [SETUP] Curl_conn_connect(block=0) -> 0, done=1
17:16:44.793039 [0-0] * Connected to ifconfig.me (34.160.111.145) port 80
17:16:44.793069 [0-0] * using HTTP/1.x
17:16:44.793149 [0-0] > GET / HTTP/1.1
17:16:44.793149 [0-0] > Host: ifconfig.me
17:16:44.793149 [0-0] > User-Agent: curl/8.15.0
17:16:44.793149 [0-0] > Accept: */*
17:16:44.793149 [0-0] >
17:16:44.793280 [0-0] * Request completely sent off
17:16:45.000968 [0-0] < HTTP/1.1 200 OK
17:16:45.001029 [0-0] < Content-Length: 13
17:16:45.001053 [0-0] < access-control-allow-origin: *
17:16:45.001074 [0-0] < content-type: text/plain
17:16:45.001092 [0-0] < date: Sat, 02 Aug 2025 07:16:44 GMT
17:16:45.001110 [0-0] < via: 1.1 google
17:16:45.001137 [0-0] <
17:16:45.001247 [0-0] * Connection #0 to host ifconfig.me left intact
***reports_your_public IP here***root@OPNsense:~ #
Also, chrome allows you to admin disable http3/quic
To disable HTTP/3 (QUIC) in Chrome, navigate to chrome://flags in the address bar, search for "Experimental QUIC protocol", and set the dropdown to "Disabled". Restart Chrome for the changes to take effect.
After disabling http3/quic nothing changes, chrome is not able to open GMail or the other site(poczta.wp.pl), same on Firefox.
As for curl:
curl -vv http://ifconfig.me
09:47:54.658000 [0-0] * Host ifconfig.me:80 was resolved.
09:47:54.661000 [0-0] * IPv6: 2600:1901:0:b2bd::
09:47:54.663000 [0-0] * IPv4: 34.160.111.145
09:47:54.665000 [0-0] * [SETUP] added
09:47:54.667000 [0-0] * Trying [2600:1901:0:b2bd::]:80...
09:47:54.669000 [0-0] * [SETUP] Curl_conn_connect(block=0) -> 0, done=0
09:47:54.674000 [0-0] * connect to 2600:1901:0:b2bd:: port 80 from :: port 56601 failed: Network unreachable
09:47:54.677000 [0-0] * Trying 34.160.111.145:80...
09:47:54.679000 [0-0] * [SETUP] Curl_conn_connect(block=0) -> 0, done=0
09:47:54.685000 [0-0] * [SETUP] Curl_conn_connect(block=0) -> 0, done=1
09:47:54.687000 [0-0] * Connected to ifconfig.me (34.160.111.145) port 80
09:47:54.690000 [0-0] * using HTTP/1.x
09:47:54.692000 [0-0] > GET / HTTP/1.1
09:47:54.692000 [0-0] > Host: ifconfig.me
09:47:54.692000 [0-0] > User-Agent: curl/8.13.0
09:47:54.692000 [0-0] > Accept: */*
09:47:54.692000 [0-0] >
09:47:54.701000 [0-0] * Request completely sent off
09:47:54.819000 [0-0] < HTTP/1.1 200 OK
09:47:54.821000 [0-0] < Content-Length: 13
09:47:54.823000 [0-0] < access-control-allow-origin: *
09:47:54.825000 [0-0] < content-type: text/plain
09:47:54.827000 [0-0] < date: Sat, 02 Aug 2025 07:47:54 GMT
09:47:54.829000 [0-0] < via: 1.1 google
09:47:54.831000 [0-0] <
46.205.201.4609:47:54.833000 [0-0] * Connection #0 to host ifconfig.me left intactAnd curl to gmail:
curl -vv https://mail.google.com/mail/u/0/
09:47:09.059000 [0-0] * Host mail.google.com:443 was resolved.
09:47:09.061000 [0-0] * IPv6: 2a00:1450:401b:800::2005
09:47:09.064000 [0-0] * IPv4: 216.58.208.197
09:47:09.066000 [0-0] * [HTTPS-CONNECT] adding wanted h2
09:47:09.068000 [0-0] * [HTTPS-CONNECT] added
09:47:09.072000 [0-0] * [HTTPS-CONNECT] connect, init
09:47:09.074000 [0-0] * Trying [2a00:1450:401b:800::2005]:443...
09:47:09.077000 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
09:47:09.079000 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0
09:47:09.082000 [0-0] * [HTTPS-CONNECT] adjust_pollset -> 1 socks
09:47:09.084000 [0-0] * connect to 2a00:1450:401b:800::2005 port 443 from :: port 56557 failed: Network unreachable
09:47:09.088000 [0-0] * Trying 216.58.208.197:443...
09:47:09.090000 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
09:47:09.093000 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0
09:47:09.095000 [0-0] * [HTTPS-CONNECT] adjust_pollset -> 1 socks
09:47:09.098000 [0-0] * schannel: disabled automatic use of client certificate
09:47:09.101000 [0-0] * ALPN: curl offers http/1.1
09:47:09.103000 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
09:47:09.106000 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0
09:47:09.108000 [0-0] * [HTTPS-CONNECT] adjust_pollset -> 1 socks
09:47:09.127000 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
09:47:09.130000 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0
09:47:09.133000 [0-0] * [HTTPS-CONNECT] adjust_pollset -> 1 socks
09:47:09.136000 [0-0] * ALPN: server accepted http/1.1
09:47:09.138000 [0-0] * [HTTPS-CONNECT] connect+handshake h2: 63ms, 1st data: 38ms
09:47:09.141000 [0-0] * [HTTPS-CONNECT] connect -> 0, done=1
09:47:09.143000 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=1
09:47:09.146000 [0-0] * Connected to mail.google.com (216.58.208.197) port 443
09:47:09.150000 [0-0] * using HTTP/1.x
09:47:09.152000 [0-0] > GET /mail/u/0/ HTTP/1.1
09:47:09.152000 [0-0] > Host: mail.google.com
09:47:09.152000 [0-0] > User-Agent: curl/8.13.0
09:47:09.152000 [0-0] > Accept: */*
09:47:09.152000 [0-0] >
09:47:09.161000 [0-0] * Request completely sent off
09:47:09.188000 [0-0] < HTTP/1.1 302 Found
09:47:09.190000 [0-0] < Content-Type: application/binary
09:47:09.192000 [0-0] < Vary: Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site
09:47:09.195000 [0-0] < Location: https://accounts.google.com/ServiceLogin?service=mail&passive=1209600&osid=1&continue=https://mail.google.com/mail/u/0/&followup=https://mail.google.com/mail/u/0/&emr=1
09:47:09.201000 [0-0] < Strict-Transport-Security: max-age=10886400; includeSubDomains
09:47:09.204000 [0-0] < Cross-Origin-Resource-Policy: same-site
09:47:09.206000 [0-0] < Permissions-Policy: ch-ua-arch=*, ch-ua-bitness=*, ch-ua-full-version=*, ch-ua-full-version-list=*, ch-ua-model=*, ch-ua-wow64=*, ch-ua-form-factors=*, ch-ua-platform=*, ch-ua-platform-version=*
09:47:09.212000 [0-0] < Date: Sat, 02 Aug 2025 07:47:09 GMT
09:47:09.215000 [0-0] < Server: ESF
09:47:09.217000 [0-0] < Content-Length: 0
09:47:09.219000 [0-0] < X-XSS-Protection: 0
09:47:09.221000 [0-0] < X-Frame-Options: SAMEORIGIN
09:47:09.223000 [0-0] < X-Content-Type-Options: nosniff
09:47:09.225000 [0-0] < Alt-Svc: clear
09:47:09.228000 [0-0] <
09:47:09.229000 [0-0] * Connection #0 to host mail.google.com left intactAnd to poczta.wp.pl:
curl -vv https://poczta.wp.pl/w/mails
09:48:38.651000 [0-0] * Host poczta.wp.pl:443 was resolved.
09:48:38.656000 [0-0] * IPv6: (none)
09:48:38.658000 [0-0] * IPv4: 193.17.41.249
09:48:38.660000 [0-0] * [HTTPS-CONNECT] adding wanted h2
09:48:38.662000 [0-0] * [HTTPS-CONNECT] added
09:48:38.664000 [0-0] * [HTTPS-CONNECT] connect, init
09:48:38.666000 [0-0] * Trying 193.17.41.249:443...
09:48:38.669000 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
09:48:38.671000 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0
09:48:38.674000 [0-0] * [HTTPS-CONNECT] adjust_pollset -> 1 socks
09:48:38.676000 [0-0] * schannel: disabled automatic use of client certificate
09:48:38.680000 [0-0] * ALPN: curl offers http/1.1
09:48:38.682000 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
09:48:38.685000 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0
09:48:38.688000 [0-0] * [HTTPS-CONNECT] adjust_pollset -> 1 socks
09:48:38.690000 [0-0] * [HTTPS-CONNECT] connect -> 0, done=0
09:48:38.693000 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=0
09:48:38.695000 [0-0] * [HTTPS-CONNECT] adjust_pollset -> 1 socks
09:48:38.699000 [0-0] * ALPN: server accepted http/1.1
09:48:38.701000 [0-0] * [HTTPS-CONNECT] connect+handshake h2: 34ms, 1st data: 23ms
09:48:38.704000 [0-0] * [HTTPS-CONNECT] connect -> 0, done=1
09:48:38.706000 [0-0] * [HTTPS-CONNECT] Curl_conn_connect(block=0) -> 0, done=1
09:48:38.709000 [0-0] * Connected to poczta.wp.pl (193.17.41.249) port 443
09:48:38.712000 [0-0] * using HTTP/1.x
09:48:38.713000 [0-0] > GET /w/mails HTTP/1.1
09:48:38.713000 [0-0] > Host: poczta.wp.pl
09:48:38.713000 [0-0] > User-Agent: curl/8.13.0
09:48:38.713000 [0-0] > Accept: */*
09:48:38.713000 [0-0] >
09:48:38.723000 [0-0] < HTTP/1.1 302 Moved Temporarily
09:48:38.725000 [0-0] < Server: nginx
09:48:38.727000 [0-0] < Date: Sat, 02 Aug 2025 07:48:38 GMT
09:48:38.729000 [0-0] < Content-Type: text/html
09:48:38.731000 [0-0] < Content-Length: 138
09:48:38.734000 [0-0] < Connection: keep-alive
09:48:38.736000 [0-0] < Location: https://poczta.wp.pl/login/v1/reload
09:48:38.738000 [0-0] < Cache-Control: no-cache
09:48:38.740000 [0-0] < Accept-CH: device-memory, dpr, width, viewport-width, rtt, downlink, ect, sec-ch-ua, sec-ch-ua-platform, sec-ch-ua-mobile, sec-ch-ua-full-version-list, sec-ch-ua-platform-version, sec-ch-ua-arch, sec-ch-ua-bitness, sec-ch-ua-model
09:48:38.747000 [0-0] < Accept-CH-Lifetime: 604800
09:48:38.751000 [0-0] <
<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
09:48:38.753000 [0-0] * Connection #0 to host poczta.wp.pl left intact
So it seems OPNsesnse supports PMTU discovery, when the original IP datagram exceeds 1492 bytes, and OPNsense sends back the ICMP Destination unreachable (type 3), Fragmentation needed (code 4), with the correct MTU of next hop g/w = 1492 bytes....see below...
It does, I do the same for my PPPoE. I use PMTU.
For it to work the firewall must allow ICMP(v4). If its blocked everywhere PMTu cannot work.
So I spun up a ubuntu vm on proxmox to test if linux browser would work, and it does (linux.png).
So something broke for windows 10, or my windows install broke immediately after upgrade of OPNsense, in less then 5 minutes after.
I found a hint
ping poczta.wp.pl -M want -s 1500
PING poczta.wp.pl (193.17.41.249) 1500(1528) bytes of data.
From router.ulanow.local.ulanow.local (192.168.1.1) icmp_seq=1 Frag needed and DF set (mtu = 1484)MTU on wan is set to 1492 and no MSS
And with MSS set to 1452 I'm able to do this:
ping poczta.wp.pl -M want -s 1456
PING poczta.wp.pl (193.17.41.249) 1456(1484) bytes of data.
1464 bytes from rev-249.go2.pl (193.17.41.249): icmp_seq=1 ttl=60 time=5.78 ms
1464 bytes from rev-249.go2.pl (193.17.41.249): icmp_seq=2 ttl=60 time=5.17 ms
1464 bytes from rev-249.go2.pl (193.17.41.249): icmp_seq=3 ttl=60 time=5.39 ms
^C
--- poczta.wp.pl ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 5.166/5.445/5.779/0.253 msBut with MTU 1484 and MSS 1444 I get no response for size 1452 but get fragmentation response for 1456:
ping poczta.wp.pl -M want -s 1456
PING poczta.wp.pl (193.17.41.249) 1456(1484) bytes of data.
From router.ulanow.local.ulanow.local (192.168.1.1) icmp_seq=1 Frag needed and DF set (mtu = 1476)
^C
--- poczta.wp.pl ping statistics ---
4 packets transmitted, 0 received, +1 errors, 100% packet loss, time 3067ms
root@proxmox:~# ping poczta.wp.pl -M want -s 1452
PING poczta.wp.pl (193.17.41.249) 1452(1480) bytes of data.
^C
--- poczta.wp.pl ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8231ms
I encountered similar issues with HTTPS timeouts on some websites. Wireshark indicated a successful TLS handshake, but no application data was transmitted afterward. This led me to suspect an MTU/MSS mismatch.
After some research, I found several posts on forums and Reddit mentioning MTU/MSS-related problems with PPPoE connections. I'm not entirely sure whether the issue already existed in 25.1 and I simply didn't notice it, or if it first appeared for me with 25.7.
As a temporary workaround, I manually set the MSS on the LAN interface to a lower value (e.g., 1200), which resolved the issue partially. However, setting the MSS via the "Firewall: Settings: Normalization" feature had no noticeable effect.
On the WAN interface, MTU and MSS were initially unset. Running ifconfig showed a default MTU of 1500 on the physical interface, and 1492 on the PPPoE interface, which is expected. Once I explicitly set the WAN interface MTU to 1492 and MSS to 1452, all connections, including those over VPN tunnels, began working properly again.
When MTU is set to 1492, the PPPoE MTU is automatically reduced to 1484. I ended up setting the WAN MTU back to 1500 and manually defining the MSS as 1452. With this configuration, all services are currently functioning as expected. ifconfig still reports 1500 on the WAN and 1492 on the PPPoE interface, as before.
For context: prior to this, I never explicitly configured MTU or MSS settings, and everything worked out of the box.
Do you also have to use vlan for PPPoE connection?
Also could you share your setup for PPPoE and WAN?
I tried to do the same an issue still persists on windows.
Yes, vlan for pppoe.
Standard vlan device linked with the point-to-point device. Selected PPPoE in WAN / IPv4 Configuration Type, nothing special. I have dual stack on my wan interface, with IPv6 no issues occoured so far as I know, only with IPv4 server.
Set MTU 1500, MSS 1452 in Interfaces / WAN
Here is my ifconfig with wan interface and pppoe:
ix1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4803828<VLAN_MTU,JUMBO_MTU,WOL_UCAST,WOL_MCAST,WOL_MAGIC,HWSTATS,MEXTPG>
ether XX:XX:XX:XX:XX:XX
media: Ethernet autoselect (1000baseT <full-duplex,rxpause,txpause>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
description: WAN (wan)
options=0
inet XX.XX.XX.XX --> XX.XX.XX.XX netmask 0xffffffff
inet6 XXXXXXXXXXXXX%pppoe0 prefixlen 64 scopeid 0x1a
inet6 XXXXXXXXXXXXXXXXXXXXX prefixlen 64 autoconf pltime 1800 vltime 14400
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
IDK about changes in new releases, I always solve that problem like this (https://forum.opnsense.org/index.php?topic=45658.0).
So I followed you instructions and got 1476 using the mentioned script
And set the MTU to this values
pppoe0 1476
vlan0.35 1484
igc0 1486
But is is still not loading some https sites
Can I use "opnsense-revert -kr 25.1.12" to revert to least know working version from 25.7.1?
You are clearly miscalculating some values and/or misreading the instructions.
If you have PPPoE on top of a VLAN, you will have some MTU X on your igc0 (physical interface), then, in theory, you will have 4 bytes less on the VLAN and 8 bytes less for PPPoE, so the difference between the MTU on igc0 and pppoe0 cannot be 10, but should be 12.
Also, the script takes all of this into account and tells you the final (i.e. PPPoE) MTU.
So, if it says you can do 1476 at most, you should set:
pppoe0 1476
vlan0.35 1484
igc0 1488
This is very strange, however, because almost any physical interface can do 1500 (which would not hurt in your situation, either).
I suspect that your initial measurement was done after you already mucked around with some of these values.
The instructions tell you to even enlarge the physical MTU by 12 bytes (if you interface supports it) in order to keep 1500 on the PPPoE interface, because that causes less problems in the long run.
Also, keep in mind that you cannot reliably set all of these values dynamically. They sometimes work only after a proper reboot.
So I set MTU to:
pppoe0 1500
vlan0.35 1508
igc0 1512
Restarted router (pc with opnsense)
Run the script and got MTU of 1492
And set MTU to this:
pppoe0 1492
pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
description: WAN (opt6)
options=0
inet 100.73.222.158 --> 213.158.195.232 netmask 0xffffffff
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>vlan0.35 1500
vlan0.35: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN_VLAN (opt8)
options=4600703<RXCSUM,TXCSUM,TSO4,TSO6,LRO,RXCSUM_IPV6,TXCSUM_IPV6,MEXTPG>
ether 02:76:c6:01:35:0b
groups: vlan
vlan: 35 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
igc0 1504
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1504
description: WAN_INTERFACE (opt7)
options=4e427bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
ether 02:76:c6:01:35:0b
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Another restart of router + windows PC
And with MTU on PC being set to 9000 I still have problems with some https sites
They go away if it is set to 1400
Does any one know if the command "opnsense-revert -kr 25.1.12" can be used to revert to working version?
Or do I have to reinstall and restore?
But PMTU should work correctly.
Here is my PPPoE with VLAN, no MSS or MTU settings has been adjusted anywhere. It's just standard ICMP:
16:35:35.811489 IP opn-dev-01.gast.example.org.35152 > lb-140-82-121-4-fra.github.com.ssh: Flags [.], seq 22:1482, ack 772, win 64948, length 1460
16:35:35.811568 IP 172.16.1.1 > opn-dev-01.gast.example.org: ICMP lb-140-82-121-4-fra.github.com unreachable - need to frag (mtu 1492), length 576
16:35:35.811571 IP opn-dev-01.gast.example.org.35152 > lb-140-82-121-4-fra.github.com.ssh: Flags [P.], seq 1482:1590, ack 772, win 64948, length 108
16:35:35.811612 IP 172.16.1.1 > opn-dev-01.gast.example.org: ICMP lb-140-82-121-4-fra.github.com unreachable - need to frag (mtu 1492), length 576
16:35:35.811961 IP opn-dev-01.gast.example.org.35152 > lb-140-82-121-4-fra.github.com.ssh: Flags [.], seq 22:1474, ack 772, win 65535, length 1452
It tries to communicate with MSS 1460 first, gets a need to frag (mtu 1492), and then tries again with MSS 1452
MSS 1460 fails
MSS 1452 works
Client caches the 1452 value and uses it for all connections.
You obviously did not follow the instructions in the linked article closely:
QuoteAs an example, if you have a WAN over PPPoE over VLAN, you should have to set WAN MTU = 1500, PPPOE VLAN = 1508, ethernet port = 1512, and it really only works for me with these tightly controlled MTUs:
pppoe0 MTU: 1500 (this must only be set in the advanced settings of pppoe0, not on the WAN interface itself, see screendumps). This will set the WAN MTU.
ONT MTU: (this means the physical ethernet port): 1512 if you have a VLAN for PPPoE, 1508 if not.
PPPOE VLAN MTU: 1508 (if needed in your setup).
To be able to set these values, you will have to assign each of the underlying interfaces a name, which you would normally not need to.
Also, set the above values in the web UI and then reboot, if in doubt - the values sometimes cannot be successfully changed via UI manipulations, because the order of application seems to be wrong that way.
Afterwards, verify that the shown MTUs are as expected via "ifconfig". Also verify that the achievable MTU over your WAN connection works with the tool I linked above.
The result you are seeing seems to indicate you only set some of the values or in the wrong place.
I see:
igc3: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1512
...
igc3_vlan40: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1508
...
pppoe0: flags=10089d1<UP,POINTOPOINT,RUNNING,NOARP,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
And I have set igc3 to 1512, pppoe0 to 1500 (in the advanced settings of the PPPoE interface, NOT on WAN!), and you cannot set the VLAN MTU manually.
P.S.: PMTU works correctly under the assumptions Monviech made, i.e. on the OpnSense side. Whether the destination supports it, is a whole different story, which is why I recommend to simply enlarge the resulting MTU to 1500 bytes (that works more often than not).
I've now compared two Wireshark tcpdumps. One was captured while I was still experiencing connection issues. The destination in both cases is a FritzBox connected via IPsec. I believe the behavior is similar with other destinations as well (for testing, I accessed the German adac.de website).
In the problematic dump, the connection starts with an MSS of 1460, which is then reduced to 1374. However, with this MSS, no data is transmitted.
In comparison, the tcpdump I captured today also starts with an MSS of 1460 but gets reduced to 1366. In this case, the connection works correctly, and the website loads as expected.
It seems that something is off with automatic MSS clamping. When neither MTU nor MSS is explicitly set, the connection fails. However, once I manually configure MTU 1500 and MSS 1452 on the WAN interface (not the pppoe interface in advanced), the connection works reliably.
I have set it up as in screenshots right now
...so completely different from what I told. There is literally no screendump that shows the correct settings.
Yes, first I used values you have provided, it did not work
then I executed the script to calculate MTU and it gave me 1492
I used it to calculate the MTU of other ones
PPPoE0 MTU 1492
VLAN0.35 MTU 1500
IGC0 MTU 1504
Is this wrong with the script output?
If yes could you tell me what values should I use? And where to set them?
Again: The script output will show you what is effective after you have set whatever you like. 1492 will almost always be the default if you set nothing at all. Theoretically, it should be 1488 with both PPPoE and VLAN, but in fact, the 4 bytes VLAN are neglegible, so 1492 still works.
So, in order to enlarge the WAN MTU effectively to 1500 bytes, you have to set the values as instructed. Iff that fails and after a reboot you still only get 1492, you may be one of the rare cases where your ISP does not support enlarging the ethernet MTU on the raw interface to 1512 bytes. This rarely happens, but YMMV.
I use the settings as given and it looks like this:
2025-08-06 19_08_36-[WAN] _ Interfaces _ OPNsense.mgsoft – Mozilla Firefox.png
2025-08-06 19_09_17-Point-to-Point _ Devices _ Interfaces _ OPNsense.mgsoft – Mozilla Firefox.png
2025-08-06 19_22_53-[ONT] _ [LOCAL_VLANS] _ Interfaces _ OPNsense.mgsoft – Mozilla Firefox.png
I do not set the VLAN MTU explicitely.
You can see that my ifconfigs who the expected sizes and the script output is 1500 for me (because my ISP allows it).
I set it up exactly like in your screenshots, restarted the router, and I still get the broken behavior of forever loading page for at least this sites:
poczta.wp.pl
mail.google.com
What does the script say after the settings and what does ifconfig show?
Script output:
./mtuScript.sh poczta.wp.pl
./mtuScript.sh: line 1: $: command not found
Maximum MTU size: 1474
./mtuScript.sh mail.google.com
./mtuScript.sh: line 1: $: command not found
Maximum MTU size: 1228
Ifconfig:
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1512
description: WAN_ONT (opt4)
options=4e427bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
ether 02:76:c6:01:35:0b
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>vlan0.35: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=4600703<RXCSUM,TXCSUM,TSO4,TSO6,LRO,RXCSUM_IPV6,TXCSUM_IPV6,MEXTPG>
ether 02:76:c6:01:35:0b
groups: vlan
vlan: 35 vlanproto: 802.1q vlanpcp: 0 parent interface: igc0
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (opt6)
options=0
inet 100.74.2.8 --> 213.158.195.232 netmask 0xffffffff
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
Well, yes, the call syntax of the find_mtu script is for a known IPv4 that supports PMTU, like 8.8.8.8, so poczta.pl does not even work here, because it is reached via IPv6. Also, the line1: error indicates that you did not download the correct script or it was converted with incorrect line-endings or something.
Same goes for mail.google.com, it is also resolved to an IPv6. Use IPv4s, not names, like "./mtuScript.sh 8.8.8.8", but verify that the script content is valid beforehand.
The ifconfig output looks about right.
For IPv6 I don't have it, my ISP does not support it, and I blocked it in config.
As for script for 8.8.8.8:
./mtuScript.sh 8.8.8.8
Maximum MTU size: 1474
That means you obviously cannot use more than that, which is quite uncommon. Somehow it seems your ISP limits you to that. So you will have to limit the WAN MTU to that value at most. It should work then. Usually, you can at least get 1488 with these kind of setups.
With that lower MTU, you should be good even for sites that do not work with PMTU. IDK if you LAN clients will automatically adapt to that lower MTU, so you probably need MSS clamping for the lower MTU, as well. I never bothered to make such adjustments, because I can use 1500 bytes.
@meyergru: your suggestion or how-to is mainly about maximizing the MTU size to avoid fragmentation, which makes sense. But @Deltorek112 and I are dealing with a more basic issue around MSS clamping.
Up until now, neither of us had ever set any MTU or MSS values manually and everything just worked. That's no longer the case, and now we need to adjust things by hand to get stable connections.
As I mentioned in post #20, there's a small difference — exactly 8 bytes — with MSS clamping before and after setting MTU and MSS manually. I think it might be related to the 8-byte overhead from the PPPoE interface. For some reason, the automatic MSS clamping doesn't seem to work properly anymore.
Just guessing here, but: there was an MTU-related change issued here (https://github.com/opnsense/src/issues/235). Could that be connected to the problems we're seeing now?
So, I reinstalled 25.1.12, and restored settings(from before upgrade). And it works fine, no need to set anything.
So I would say something changed from this version to 25.7 and it broke MSS clamping or something associated with that.
@mbk2: I know, I just wanted to present a fix where you do not have to rely on the MSS clamping, which in the past did not work for me, as well. Of course, that fix only works if your ISP allows it.