pfSense

confirmed on 7100 running 23.01 - after setting mtu/mss and rebooting system receives and displays IP on WAN in console but gui cannot be reached and ping test from console reports sendto: network is down, trying to ping from a different host returns destination host unreachable.

We had a customer complaining about similar behavior at Netgate 2100. However, I couldn't reproduce this behavior on Netgate 2100. I defined MTU/MSS on mvneta0 and mvneta1, and everything worked fine. It seems that only XG-7100 is affected.

Is there any progress here?
This is serious bug which affects all XG-7100s path MTU discovery.
Is there any workaround for this please?

I think i may be affected by this on a Netgate 3100. I had an MTU set on WAN interface 1480, which had been seemingly been working properly for ages on 22 series. I then upgraded to 23.01 yesterday, and started having really strange intermittent (some sites) connection issues. Once i found this issue, i tried removing the MTU setting on the WAN interface, and things went back to normal. Should be said, i'm not sure why I had it set in the first place.

Just ran into this with another customer running 23.05.1 on a 7100. Adding an <mtu> value to any interface on the switchports will trigger this.

Other behavior notes:

If you run an ifconfig lagg0 from shell, the lagg will show up and both of the ix interfaces will show ACTIVE just fine. However, the "Assign Interfaces" option from VGA/Serial console will not show lagg0 as an assignable interface with this bug. Additionally, the vlan subniterfaces will show this for their VLAN config:

groups: vlan
vlan: 0 vlanproto: 0x0000 vlanpcp: 0 parent interface: <none>
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

All of the VLANs will show <none> for the parent interface and 0 for the VLAN tag, but the interface will still be lagg0.#### as expected.

If you manage to get into the webConfigurator post-boot and save/apply the VLANs one at a time, they will all come up including the ones with an MTU/MSS set, so it doesn't seem to be a capability issue. Probably something getting "caught up" during the process on boot.

Tested this on the Netgate 3100 and it appears to be isolated to only the 7100. Setting an MTU on LAN while using or not using 802.1q VLAN tagging does not cause any link issues on the switchports.

I seem to also be able to reproduce this behavior using the ix interfaces on cordoba platform to create a LAGG (LACP) and setting MTU to 9000 and then trying to adjust any of the child VLAN's MTU that are also on LAGG, running 23.05.1

I can confirm the issue with pfSense 2.7. We're using multiple vlan interfaces on an lagg1 interface. (lagg1.40, lagg1.41 ...) and set mtu to 1440 and mss to 1400 (due to vpn tunnels and unknown provider links).

When I create the lagg1 interface and vlan subinterfaces and change the interface assignments everything seems to work until I reboot the pfsense (vm via libvirtd). Using the the same mtu/mss settings on a non-lagg interface (vtnet0 for example) works like expected.

Daniel Hoffend wrote in #note-12:

I can confirm the issue with pfSense 2.7. We're using multiple vlan interfaces on an lagg1 interface. (lagg1.40, lagg1.41 ...) and set mtu to 1440 and mss to 1400 (due to vpn tunnels and unknown provider links).

When I create the lagg1 interface and vlan subinterfaces and change the interface assignments everything seems to work until I reboot the pfsense (vm via libvirtd). Using the the same mtu/mss settings on a non-lagg interface (vtnet0 for example) works like expected.

Hello Daniel,

Do you see the same issue as I mentioned earlier regarding the sub-interfaces showing <none> for the parent interface? Please advise.