Thread Info
  • Locked Locked
  • Replies 66 replies
  • Subscribers 26 subscribers
  • Views 223664 views
  • Users 0 members are here
Options
Suggested
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"

Vegard77Norway

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.
  • in reply to jdmoore0883

    jdmoore0883 said:

    I am with Rogers here in Ottawa as well, and can confirm that the steps above DO indeed work as advertised.

    As for Rogers, I have opened a ticket with them last week to have this addressed, but I haven't gotten any updates of value since. I have requested escalation on the case, and filed some complaints, but I doubt this will be addressed at all anytime soon (if at all, ever). I would suggest you get your client to file a case/complaint as well, and maybe even yourself if you can, and maybe (just MAYBE), if we get enough people screaming about this they just MIGHT do something about this.

    The real problem here, in my opinion, is with the DHCP server that is handing out such tiny MTUs. An MTU of 576 seems to be a hold-over from ye ole' dial-up days... And if this, a very basic configuration, hasn't been addressed since that time, what else within that infrastructure is just as equally outdated? What about security? Has any of the infrastructure security been updated since then? But I digress...

    I have been told there is new pricy ($$) equipment being delivered with a default MTU on the DHCP server of 576. Did not get a vendor to name and shame.

    My understanding is that Sophos did this change (NUTM-2840) on the request of Amazon EC2 customers needing jumbo frames.

    Happy you are able to put the "fix" to good use. 

    Edit: Page 3 snipe!

  • in reply to jdmoore0883

    I am with Rogers as well in Toronto. I have also opened a ticket with Rogers to see if they can change their MTU settings, so far I'm not holding out much hope. I work in networking and you'd be surprised by some of things i see in customer networks

  • in reply to Vegard77Norway

    I worked back in the dialup days(and am a Sophos partner) and 576 would not have been a desirable MTU then either.

    I spoke with a Rogers tech today who implied if this [MTU setting] was the case he would know...

    I don't currently have a way to confirm this but I suspect this is not a Sophos issue. However, it would be nice if a) the GUI in the utm respected the setting the user set and/or b)would not let a DHCP server set an unhealthy value.

    I have 3 other clients on Rogers(as secondary connection) in Ottawa that have a utm I can cross reference this with. I'll post back once investigate this further.

  • in reply to plecavalier

    plecavalier said:

    I worked back in the dialup days(and am a Sophos partner) and 576 would not have been a desirable MTU then either.

    I spoke with a Rogers tech today who implied if this [MTU setting] was the case he would know...

    I don't currently have a way to confirm this but I suspect this is not a Sophos issue. However, it would be nice if a) the GUI in the utm respected the setting the user set and/or b)would not let a DHCP server set an unhealthy value.

    I have 3 other clients on Rogers(as secondary connection) in Ottawa that have a utm I can cross reference this with. I'll post back once investigate this further.

    My ISP took two weeks to convince to actually check their config.

    ISP's don't belive there is a MTU setting in their DHCP server until you provide them the Wireshark transcripts. 

    In my case they actually checked the MTU on the interface of their DHCP server 5 days before looking at the DHCP config.

    The MTU value in question is provided by the MTU server through DHCP server option 26. 

     Option: (26) Interface MTU
            Length: 2
            Interface MTU: 576
     
    After receiving the Wireshark transcripts, finding the problem (their DHCP config) their response to me was:
    (Google translated)
     
    "It says otherwise pretty much that we have 400,000 customers who have not reported problems, but only this one case (that we've got up here). So it is either so very few manufacturers have updated DHCP, or ignore the information they receive. As you point out, it is possible to override this (with the complications and potential vulnerabilities that may result), which is apparently being made by some of our customers."
     
    My advice.
    1) Set up a computer with Wireshark on a DHCP able computer.
    2) Do the capture of their DHCP Offer.
    3) Send them the capture transcripts (or most important part), and hope it is passed to someone who bothers to read, and does understand it.
    4) Do not expect an apology.
     
  • in reply to plecavalier

    On a side-note about the 406 update...

    If you perform the steps as noted in the original post, and then apply 406 afterwards, it will not undo the changes you have made.

    I have confirmed this on my gateway last nigh.

  • in reply to plecavalier

    I've messaged a good contact within the organization with the hopes of reaching the right tech to get this changed.

  • in reply to plecavalier

    Just tested this with a third client and it's the same. Meanwhile,  my contact was unable to summon anyone of significance at the other end. They can't even seem to help themselves....Can't push a rope!

  • Thank you for posting this - I couldn't figure out why my IPv6, Streaming, and other things had suddenly broken, and I could not modify this from 576 without going to a static IP. Glad to know I'm not the only one!

  • in reply to Vegard77Norway

    Vegard, I'm curious - would you please post or PM me the untranslated version?  I'd like to see if the French is as dismissive as the Google translation seems to be.

    Cheers - Bob

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