Bug #8113
open
MTU setting on bridge, openvpn clients ignored
0%
Description
I set the MTU field in the GUI for a pair of openvpn clients and the bridge interface to 1492.
However, the 'interfaces' display shows an MTU of 1500.
An ifconfig report via the command line shows an mtu of 1500.
Manually changing the MTU via the command line on the openvpn clients to 1492 shows the correct number afterward both on the command line and in the interfaces display.
I don't think FreeBSD has a way to change the MTU on a bridge. Not sure. Probably should grey out the fields in the interface screen for options the assigned interface can't implement.
Workaround is to put an MTU setting cron job.
Updated by Braden McGrath almost 7 years ago
It's not immediately clear to me what you are doing here. What interfaces make up the bridge? OpenVPN tap (layer2 endpoint interface) plus your LAN interface?
From the manpage for bridge(4)
The MTU of the first member interface to be added is used as the bridge MTU. All additional members are required to have exactly the same value.
Thus, it seems like it isn't possible to directly change the MTU on a bridge. It would require destruction of the bridge first, MTU change on a child interface, and then re-creation with that specific smaller-MTU child picked as the first member. I agree that the MTU field should probably be greyed out in the UI for an extant bridge interface, with a note that they must be destroyed & rebuilt to change MTU.
I'm not sure how the bridge creation code works right now, but it would seem to make sense to purposefully pick the smallest-MTU child as the "first member," and warn before actual creation that all bridge members must share the lowest common MTU (and ideally, automatically take care of changing it on other interfaces, if that is necessary / bridge(4) doesn't do it "magically" itself).
I'm not much of a coder so I can't really help beyond the thought process here, sorry!
Updated by Kris Phillips almost 3 years ago
OpenVPN's MTU is set by a command passed to the client/server, not on the interface itself.
As for bridge interfaces it's going to use the MTU of the first member as previously mentioned.
This doesn't seem like a bug.