pfSense

With the recent release of pfSense 2.5 and the removal of the VLANMTU flag requirement per [[https://redmine.pfsense.org/issues/9548]] to create VLAN interfaces. I am working to migrate some Firewall units over to XCP-ng (https://xcp-ng.org/), a Xenserver/Citrix Hypervisor alternative solution. I have setup a test environment in preparation for the migration and in my testing I have noticed an issue, it appears that the first VLAN tag defined does not follow the parent interface MTU settings. All subsequent VLAN tags follow the parent interface's MTU.

Example below, with example VLANs defined in order created within the pfSense interface top-down. Parent interface MTU of 1504:
100
101
102
103
104
105
Interface VLAN 100 will have an MTU of 1496 while interface VLAN 101-105 will have an MTU of 1500. Something to note is that manually setting the VLAN MTU works no problem until the firewall is rebooted where it reverts to 1496. Where as the re-root option sets the correct MTU for all interfaces including the first defined VLAN tag at least until the system is rebooted.

Steps to reproduce issue:

1. Setup pfSense 2.5 using an XN based NIC configured as a VLAN trunk with an MTU of 1504 within the hypervisor
2. In pfSense assign the XN trunk interface and enabled it with an MTU of 1504
3. Define two or more VLAN tags within the pfSense WEBUI on the XN trunk interface
4. Assign the VLAN tags as an interface and enable said interfaces
5. Check via ifconfig or Status->Interfaces within pfSense WEBUI and note that the first and only the first VLAN tag defined does not follow the parent interface's MTU

Additional information and steps performed with Netgate support.

• ifconfig listing interfaces as originally configured (ifconfig.txt file attached)
• ifconfig listing interfaces after changing parent MTU value to 1508 without a reboot (ifconfig_running.txt file attached)
• ifconfig listing interfaces after changing parent MTU value to 1508 after a reboot (ifconfig_startup.txt file attached)
• creating a new VLAN interface has the same behavior. The new VLAN interface follows the parent interface while the first defined VLAN tag interface remains at 1496
• adding another XN interface also has the same behavior. The first defined VLAN tag still does not follow the parent interface MTU settings

Additional things to note:

• Doing a re-root brings all VLAN tag interfaces up with the proper MTU
• Manually setting the MTU on the VLAN interface works at runtime but has no affect after a reboot
• Changing the parent's MTU happens immediately but VLAN tag interfaces only update after a reboot (did not test with re-root). Not sure if this is intended behavior.