Sophos UTM 9.407-3 released

Looks promising :-)

Fix [NUTM-4992]: [Network] Unitymedia / KabelBW customer getting always the MTU 576

I just installed and tested the MTU issues on a Sophos UTM 9 Home install using Charter cable and it is NOT fixed for me.  I have another site that is Comcast that I will test later this morning.  I guess they only fixed two ISP's from what they said.  Doesn't make much sense.

FYI I did not reboot my modem.

EDIT:  I just fully powered down the modem for a minute and same 576 MTU issue.

For NUTM-4992 a new confd option has been introduced.

For interface objects there now is a "mtu_auto_discovery" flag.
1 = take interface MTU from DHCP and overwrite value in confd (default)
0 = do not take interface MTU from DHCP

Hope that helps.

bulirich said:

For NUTM-4992 a new confd option has been introduced.

For interface objects there now is a "mtu_auto_discovery" flag.
1 = take interface MTU from DHCP and overwrite value in confd (default)
0 = do not take interface MTU from DHCP

Hope that helps.

Thanks Bulirich, I tried it and it works hooray :-)

The fix:

Login as loginuser then root in ssh shell:

cc 
RAW 
lock_override 
OBJS 
interface 
ethernet (or cable, or other type) 
REF_ (Tap TAB two times - then you can see the interface list. Mine is called "REF_IntCabExternaWan[WAN,interface,ethernet]"
(You will get a look like this:)

'additional_addresses' => [],
'bandwidth' => 0,
'comment' => 'Added by installation wizard',
'inbandwidth' => 100000000,
'itfhw' => 'REF_ItfEthEth1',
'link' => 1,
'mtu' => 576,
'mtu_auto_discovery' => 1,
'name' => 'WAN',
'outbandwidth' => 20000000,
'primary_address' => 'REF_ItfPri000024',
'proxyarp' => 0,
'proxyndp' => 0,
'status' => 1
}

Then write:

mtu_auto_discovery=0 
w  (write the changes) 

Now go into Webadmin and find the WAN link, change the MTU under Advanced to 1500 and voila! :-)

That really doesn't help people who remotely administer UTMs... Right now I don't have a stable enough connection to my branch location to get in and make that change. Now my only choice is to drive out to this location, a 3 hour drive. The default should be to ignore the MTU from DHCP as it always had in the past so it doesn't affect the ability to administer these boxes.

Dlabun said:

That really doesn't help people who remotely administer UTMs... Right now I don't have a stable enough connection to my branch location to get in and make that change. Now my only choice is to drive out to this location, a 3 hour drive. The default should be to ignore the MTU from DHCP as it always had in the past so it doesn't affect the ability to administer these boxes.

I agree with you, mtu_auto_discovery should be 0 (diabled) as default.

This is not configurable in webadmin? If not this is the most stupid fix I have seen a long time. Why would they fix it for two ISP's only. All I can say is WOW!!! It seems like such a simple concept to allow a user to enable or disabled in the webadmin instead of forcing this down our throats and make us go to a command line interface to fix

You have it all wrong... Somebody at Sophos clearly thought it'd be funny if they turned this bug fix into an easter egg customers have to find and activate. I have to drive out to one of my locations now to fix the problem, completely flushing my weekend down the drain.

I need a little help with twister5800's reply. I previously had the 576 MTU problem, and had applied VegardOestengen's suggestion from another thread, which fixed the problem. The fix continued to work after the upgrade to 9.406-3. Last night, however, I upgraded my home (software-based) UTM to 9.407-3, and it's been a disaster. Although the web interface tells me that the internet-facing interface is still using a MTU of 1500, I'm not believing it. Most websites are unreachable. Pings and traceroutes work, but not much else. I've had some experience with MTU problems before, and this pretty clearly seems to be an MTU problem. I've tried changing the MTU in the web interface to 1492, and then back to 1500, but it didn't help.

So I want to try twister5800's suggestion, but I'm lost. I know how to ssh into the UTM, but I'm not sure what to do after that. "cc", "RAW", "lock_override", etc., don't appear to be shell commands. So what's going on? Have I missed a step?

When you tipe cc and press enter you will enter kind of a second shell. Inside that shell you will type those command twister5800 provided. I'll try to explain a bit further to you:

type cc and press [enter]

You will get and output like:

Confd command-line client. Maintainer: <Ingo.Schwarze@sophos.com>

Connected to 127.0.0.1:4472, SID = VGdqvYBurSTNHXVdhnqk.
Available modes: MAIN OBJS RAW WIZARD.
Type mode name to switch mode.
Typing 'help' will always give some help.
127.0.0.1 MAIN >

This means your are inside cc shell.

type RAW and press [ENTER]

type lock_override and press [ENTER]

type OBJS and press [ENTER]

type interface and press [ENTER]

Now it gets a little tricky. Most setups which has this issue uses an ethernet type WAN, so:

type ethernet and press [ENTER]

Here you will have to "select" your WAN interface. To do that:

type REF_ (this is case sensitive) and press [TAB] two times. It should list all your ethernet type interfaces, like this:

REF_DefaultInternal[Internal,interface,ethernet]
REF_IntEthExternaWan[WAN,interface,ethernet]

On a default configuration system, it should look exactly like this, but don't worry if it doesn't. From that lines, look for the one that contains something like "REF_IntEthExternaWan" or the name of your WAN interface.After you locate the name for your WAN interface from the list, type the rest of the object name (case sensitive). To avoid any typos, you can copy and paste the rest of the object name after REF_.

For example, provided that your WAN interface is using the default name, you should then complete REF_ with:

REF_IntEthExt and press [TAB] again.

That will autocomplete the name for your WAN interface. Then, press [ENTER] again.

You should get an output iike this:

'additional_addresses' => [],
'bandwidth' => 0,
'comment' => 'Added by installation wizard',
'inbandwidth' => 100000000,
'itfhw' => 'REF_ItfEthEth1',
'link' => 1,
'mtu' => 576,
'mtu_auto_discovery' => 1,
'name' => 'WAN',
'outbandwidth' => 20000000,
'primary_address' => 'REF_ItfPri000024',
'proxyarp' => 0,
'proxyndp' => 0,
'status' => 1
}

If you do, you are in the right track. Then type:

mtu_auto_discovery=0 

and press [ENTER]

You will get the same output as before, but mind the subtle change on 'mtu_auto_discovery' line, that should now be 0.

To save, type 

w 

and press [ENTER]

this will save your configuration.

type exit and press [ENTER]

this will return to the shell.

After that, fix the MTU in Webadmin and it should not revert to 576 anymore.

Let me know how it goes.

Regards - Giovani

Thanks, Giovani! That did the trick. I was on the right track, but I must have mistyped the first ("cc") command somehow, because when I tried it earlier, I got a bash command not found error, so I didn't try to go any farther. How do you mistype a two-character command? I don't know, but I somehow managed to do it. Anyway, I followed your instructions and set mtu_auto_discovery to 0. Saved, set the MTU to 1500 (even though the web interface said it already was), rebooted the UTM (not sure if that was necessary but figured it couldn't hurt), and now everything is working again.

I'm still not sure why the web interface was showing the MTU setting was 1500 (before I applied the latest fix), when it pretty clearly (by the evidence) wasn't. Maybe that was a side-effect of the earlier patch?

You can use Giovani's fix directly from the command line...

I would start in cc to find out the REF_ of the interface you want to change:

cc
interfaces
interfaces@
exit

That lets you see the REF_s along with the WebAdmin names of the interfaces.

Assuming that you found the REF was REF_IntEthExternal, you could issue the command

cc change_object REF_IntEthExternal mtu_auto_discovery 0

To check your work:

cc get_object REF_IntEthExternal

Cheers - Bob

You can use Giovani's fix directly from the command line...

I would start in cc to find out the REF_ of the interface you want to change:

cc
interfaces
interfaces@
exit

That lets you see the REF_s along with the WebAdmin names of the interfaces.

Assuming that you found the REF was REF_IntEthExternal, you could issue the command

cc change_object REF_IntEthExternal mtu_auto_discovery 0

To check your work:

cc get_object REF_IntEthExternal

Cheers - Bob

BAlfson said:

I would start in cc to find out the REF_ of the interface you want to change:

cc
interfaces
interfaces@
exit

That is largely replaceable with "cc get interfaces"

A different approach is "cc get_interface_ref_by_hardware <interface>". Example usage "cc get_interface_ref_by_hardware eth0"

Also, out-of-band management was briefly discussed in the past, perhaps it is a topic for the community to revisit.

You can use Giovani's fix

Just to give credit where credit is due, that's Twister5800's fix, not mine. I was just explaining to Bruce, with a little more detail, how to get it done.

Regards - Giovani

The MTU fix worked like a champ for me. FYI, I'm a Comcast subscriber and after updating I was still seeing a 576 MTU size. As described above I disabled the auto-discover and manually set the MTU at 1500. This actually fixed quite a few of my UTM problems. (I'm brand new to UTM).

Thanks guys!

If you go under Interface & Routing > Interface, what do you have under interface type?

I just want to confirm this MTU issue is not affecting users that have a static IP for interface type: Ethernet