This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Disable bad bugfix in 9.405-5 "Fix [NUTM-2840]: [AWS] UTM ignores MTU sent by DHCP server"

Do not do this if you don't feel comfortable messing up your UTM. 

I'm pretty shure this voids the warranty.  But my UTM is pretty useless using a MTU of 576 from my ISP.

The 9.405-5 upgrade introduces a mandatory, non disable, usage of the MTU provided with DHCP, if one is provided.

A lot of us have ISP's that provide bad MTU values. Like my own ISP giving a MTU of 576 (Confirmed with wireshark).

This is what you need to do to disable the usage of MTU from DHCP. Beware, you will be touching the system, and also.. it will not update MTU based on any DHCP.

(I'm not telling you how to get into the UTM, if you don't know... you have no business being there... better wait for the fix.)

In the 

/var/chroot-dhcpc/etc

There is a file named: default.conf

cat default.conf

interface "[<INTERFACE>]" {
timeout 20;
retry 60;
script "/usr/sbin/dhcp_updown.plx";
request subnet-mask, broadcast-address, time-offset,
routers, domain-name, domain-name-servers, host-name,
domain-search, nis-domain, nis-servers,
ntp-servers, interface-mtu;
[<HOSTNAME>]
}

"interface-mtu" : If you remove that (not the following ;!!!), and take your interface down/up, your MTU is possible to edit by hand again in the GUI.

AND ... it will use the number you give it, not the dumb MTU value one of your ISP's let be in their equipment because they did not bother to change it.

Finally I have a UTM back up and working, and I can get back to business.



This thread was automatically locked due to age.
  • leitzr said:

    Vegard,

    You have a valid point.  I happen to know what my typical dhcp lease time is and I manually renew my lease before the 50% point, which I should have recommended.  I prefer to do this while we wait for this issue to be resolved, instead of hacking my system.

    Rick

    Hi Rick,
    I'm never going to push anybody into doing anything. Except if they are the ISP with a bad config.
    After a week of naging on my ISP they updated their MTU value on their DHCP server, so I just reverted my workaround.
    Hope Sophos does a fix, or feature update soon. 
    Best regards
    Vegard
  • It refused to route traffic after doing the manual config change.

    It would work again if I added the interface-mtu; back 

  • Hi,

    Interesting post and to update all, this is under development NUTM-4992.

    Thank you for patience.

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • Thank you for the reply. I'm sure many will be happy to see this.

    Are you able to be more specific what is being done?

    Thanks

  • Thank you very much VegardOestengen!  We have spent the last 24 hours trying to figure out why after the 9.405-5 update, users were unable to access their network shares on their NAS (QNAP). (They connect via an IPSEC site-to-site VPN). We tried quite a few troubleshooting methods until I found your post here.

    Once we made the changes on the config file in the Sophos, users were able to see the shares on the QNAP again.  Hopefully Sophos fixes this bug in the next UP2DATE patch.

    Thanks again!

  • sachingurung said:

    Hi,

    Interesting post and to update all, this is under development NUTM-4992.

    Thank you for patience.

    Thanks for the feedback!

    Next time you try to support [feature](Jumboframes at AWS) through modifcation of [featuresett](DHCP client) I hope you consider that there might be bad configs floating around. 

    AWS is like a vacation resort compared to the rest of the ISP's out there. Making modifications based on a tiny part of the ecosystem is dangerous.

    But, I guess you have re learnt that experience.

    By the way. I tried to share this with you moments after the update hit. As a homeuse license user I was not able to file a ticket.

    I don't have a problem with that. Just don't expect us to help, if we can not file tickets, and Sophos don't bother to read the forum.

    [6]

  • ChrisShill said:

    Thank you very much VegardOestengen!  We have spent the last 24 hours trying to figure out why after the 9.405-5 update, users were unable to access their network shares on their NAS (QNAP). (They connect via an IPSEC site-to-site VPN). We tried quite a few troubleshooting methods until I found your post here.

    Once we made the changes on the config file in the Sophos, users were able to see the shares on the QNAP again.  Hopefully Sophos fixes this bug in the next UP2DATE patch.

    Thanks again!

    Thanks for the feedback! Its a easy fix once you figure out who / what the culprit is, and have a blueprint to follow.

    Based on the feedback I might actually consider sharing more fix'es in the future. [:$]

    Again. Very good to know someone puts this to good use.

  • Thanks, can you let us know when the fix will be available to be applied? As you can understand this is causing quite a bit of issues, while the temp fixes may be a workaround, the proper fix would be best.

  • Hi, 

    You can report me if you find any glitch in an update. I will look into it and report the internal team but, I cannot push them for a quick fix until a support case is open.

    Thanks

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • It looks like your mistake was removing the semi-colon after and not removing the comma-space in front of interface-mtu

    Does it work after those corrections?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA