Messages

I'm seeing the same issue. I found this thread before upgrading so I blanked all the MTU boxes prior to upgrading, but putting 1508 back into the PPPoE adapter post upgrade also results in breaking a lot of the internet as other people here mentioned. I've had to go back to blank/default for now which isn't ideal.

Has anyone who has seen this issue tried 26.1.2 yet? I am stumped.

EDIT: Setting WAN MTU to Blank on 25.7.11_9, and upgrading to 26.1.2 and then setting it back to 1508 works. It now works as before, and gives expected results of 1440 and 1460 here http://pmtud.enslaves.us/

I'm seeing the same issue. I found this thread before upgrading so I blanked all the MTU boxes prior to upgrading, but putting 1508 back into the PPPoE adapter post upgrade also results in breaking a lot of the internet as other people here mentioned. I've had to go back to blank/default for now which isn't ideal.

AHH, that saves me trying that then. Clearly something has changed in the implementation but it only affects a subset of previously working setups.

I would roll back to 25.7.11_9, delete your wan mtu and leave it blank, reboot. Then update to 26.1 and re-enter your wan mtu 1508. Maybe there's some shenanigans during the update

That's not a bad idea. It's possible I've already tried that, but I'll re-visit later when the house is empty.

This does not look like an MTU issue if you can use those ping sizes - it look just fine.

Did you also use traffic shaping? Maybe the old ISP had lower speeds and you shape it to fit? Happened before...

Just saw that you disabled all shaping...

No idea what could be wrong.

It's a weird one, isn't it!?

When I've got more time I'll try a 3rd update from the working 25.7 snapshot.

I'm on BT PPPOE (Openreach) and just set the wan mtu to 1508 without any issues on websites. Are you on Zen Openreach or Zen City Fibre?

Openreach. As said, been running that config with no issues since around 23.7.5 and as per Meyergru (with physical interface explicitly stated) before that.

Upgrade to 26.1 breaks something. I've done it twice now, same result.

Are you using DNSmasq Router Advertisements or RADVD? I was seeing some peculiarities on some websites unless I explicity set the RA MTU in DNSmasq. Switch to RADVD (if you're using DNSmasq RA) and see if your issues persist

I'm using RADVD. I am sure I tried explicitly setting the MTU there also. Did something change between 25.7.11_9 and 26.1 in the Router Advertisements - was the issue you saw only after 26.1 upgrade?

Issues are across IPv4 and IPv6 - they persist if I disable IPv6 on my client machine.

I am at a loss. I have just got home, and further looked at your setup meyergru. I realised that this is how I originally had it set up (as  was required before) - Create/Assign the igb0 (in my case) physical interface and explicitly set a 1508 MTU (I have no VLAN requirement), then on the PPPoE point to point link that sits on it configure the link MTU as 1500.

There was an update to OPNSense (23.7.5 ish?), where it was stated that explicitly creating the parent interface was no longer required and setting the MTU to 1508 on the [WAN] interface would correctly set the adaptor/physical interface MTU and the Child PPPoE link (as per the calculated MTU shown @1500) - this has worked since then.

So, I have recreated the config as per yours (and rebooted) - with the parent/physical interface and I still have the same issues. I get the sub-optimal results on the Path MTU Discovery Test, and the internet is 'broken' - sites loading slowly, 30-50% line rate on the download, speedtest.net failing to run the test at all. Upload not affected.

Small bit of digging:

• ifconfig shows (physical interface) igb0: at 1508 MTU
• ifconfig shows pppoe0: at 1500 MTU
• ping -D -s 1472 google.com returns 1480 bytes
• ping6 -D -s 1452 google.com returns 1460 bytes

so I can see the MTU is set correctly . But still, I have those results and everything feels 'broken'.

Roll back to 25.7.11_9 and all is well, but I see no difference in the config or what ifconfig reports. 

Is there anything I can do to try and narrow down the cause? I don't want to be stuck on 25.7 for all time.....

I'm hoping someone might see this, and recognise *something* that changed in 26.1 that may affect this, even if it is a really weird edge case specific to my use-case. I can then (hopefully) mitigate it - but as far as I can see, there is nothing different/special about my WAN setup.

Thanks Meyergru - maybe I'll try replicating your settings, minus the VLAN as that is not required.

That being said, setting the WAN MTU on the first page to 1508 directly was enough up until now (after it changed where you didn't need to separately set up the parent interface) - it seems something has changed in 26.1 that means the more detailed setting might be required....

[25.7.11_9]

Changed the title - my issues seem to be across IPv4 and IPv6 and relate to the MTU implementation (somehow) on 26.1.1. I have 1508 MTU Set on my PPPoE WAN Interface (Calculated PPP: 1500) and that has worked forever. When I upgrade to 26.1.1 I have MTU/MSS related issues. I can flip back and forth from 25.7.11_9 to 26.1.1 and the issue is entirely repeatable on 26.1.1.

If I run the Path MTU Discovery Test, it illustrates the issue - http://pmtud.enslaves.us/

Attached screenshots

25.7.11_9 - IPv4 MSS OK to 1460, and IPv6 MSS OK to 1440 (as expected)

26.1.1 - IPv4 MSS 536, and IPv6 MSS 1220

Something is amiss and this is entirely repeatable.

Has something changed in the implememtation of Mini Jumbo on the WAN Interface?

[on 25.7:]

I am pretty sure this is an IPv6 MSS/MTU issue I'm seeing on 26.1, that I did not see/was not there in previous versions. I noticed speedtest.net was resolving to an IPv6 address and did some more investigation.

I have changed nothing, but 26.1.1 breaks something. I have 1508 set for my WAN PPPoE MTU (Calculated 1500 PPP) - does 26.x do something different on the IPv6 MTU/MSS with this that it wasn't doing before or not doing something now that it was in previous versions?

Do I have to manually clamp the IPv6 MTU/MSS now somehow/somewhere on 26.1 that wasn't required previously? I did nothing on 25.7 and had no issues.

on 25.7:

• ping -6 -l 1452 google.com - Pings get returned.

However on 26.1:

• ping -6 -l 1452 google.com - I get a timeout (packet silently dropped)
• ping -6 -l 1440 google.com - Pings get returned.

Any help would be appreciated - is this a behaviour change I now need to mitgate with some additonal settings, or a bug?

Thanks.

EDIT: Could it actually be IPv4 also? Thinking about it, I seemed to have issues on VLANs/interfaces that do not have IPv6 enabled. I have gone back to 25.7.9_4 for now so can't check.

I remember some time ago there was some shenanigans with setting an MTU of 1508 and it not being correctly applied to the interface /you had to do something else at the parent interface level, until the implementation was changed to fix it.

Hi all, I upgraded from 25.7.11_9 directly to 26.1.1 as I elected to wait for the *.1 patch before I made the move.

Immediately upon upgrading, my internet has become 'troublesome', generally laggy with slow notifications from my cameras etc. One thing that is entirely repeatable is speedtests are significantly reduced, when they run. If I try speedtest.net it seems to take ages finding the optimal server, and when I run the speedtest I get about 400-600 down on a 950 connection, after it taking a while to start. On occasion, it fails to run the speedtest at all and throws an error.

If I go back to my 25.7.11_9 snapshot, all is well again. If I return to the 26.1.1 snapshot, back to the same problems consistently.

I have had a poke about, and cannot see anything obvious. But, consistently 25.7.11_4 is fine, and 26.1.1 has these issues. I run a pppoe connection with Zen in the UK. MTU for the WAN Interface is set to 1508 (for Calculated PPP MTU:1500) as it has always been. Changing this to 1500 made no difference - for some reason it smelt a bit like an MTU issue. I have disabled any shapers/pipes, Zenarmor and no different. Going back to 25.7.9_4 solves it instantly.

Where can I start looking / what can I do to try and narrow down the issue? I am keen to work it out and stay on 26.1.1. Thanks.

Upload appears not to be affected

Finally got around to installing this, and bought a plus license. Nothing much to add beyond the feedback already given - very impressed!

Agree with Seimus comments on VPN endpoints above

I don't think I've seen a comment for these:

-The manual/setup instructions don't explicitly tell you to enable logging for the rules you set up - that might not be obvious for less experienced users.

-Also when talking about Source/Destination and Block/Reject it says "For your LAN (source) rule you could use Reject" - per the rule examples is that not Rule 1 / Destination (rather than source)? 

How long before we might be able to utilise Domains and URLs feeds in OPNSense?

This sounds really good. I'm not sure I'd be able to offer any useful feedback, but I am very likely to deploy this at home - when is 'general availability' forecast? Thanks.

This position might make me reconsider my subscription to be honest. Multi core support for core functions is not really a 'power user' option when you offer IPS and Filtering policies as part of the Home subscription, but for many they are unusable on what is now a fairly standard 900mbps home connection if you want full throughput. How do you define 'broader home community?' I daresay that community probably doesn't use a next gen firewall, need 5 policies, use IPS, or even uses Zenarmor (or indeed OPNSense) at all! There wasn't multi-core support when I started my subscription, but I didn't realise that and was surprised, and later found I could not use the IPS as a result. When I thought it was a technical limitation it was annoying but something I tolerated whilst frequently considering if I was actually getting good value. Now the omission of multi-core support is a purely commercial decision, that shifts the balance for me.

One for me to think about carefully over the coming days.

Oooh this looks interesting. I have wanted to use PPSK via freeradius on Omada for a while - I am currently doing it by WiFi password which is quite annoying. How do I use your patch?