Thread Info
  • Locked Locked
  • Replies 87 replies
  • Subscribers 33 subscribers
  • Views 113219 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

Up2Date 9.405005 available

Ben

Got an Up2Date Msg on our SG 230 just an hour ago:

Remarks:
System will be rebooted
Configuration will be upgraded
Connected REDs will perform firmware upgrade
Connected Wifi APs will perform firmware upgrade

News:
Maintenance Release

Bugfixes:
Fix [NUTM-2840]: [AWS] UTM ignores MTU sent by DHCP server
Fix [NUTM-3064]: [AWS] Confd info shows wrong instance_role for ha warm&as
Fix [NUTM-4426]: [AWS] Allow root login with SSH per default on AWS
Fix [NUTM-4516]: [AWS] factory reset doesn't clean up completly on AWS
Fix [NUTM-1775]: [Access & Identity] 35668: DHCP Broadcast over all RED LAN ports causing wrong IP address assignment
Fix [NUTM-4129]: [Access & Identity] Update OpenSSL in SSLVPN client
Fix [NUTM-4216]: [Access & Identity] STAS related argos coredumps in v9.403
Fix [NUTM-4258]: [Access & Identity] RED15/RED50 standard / split doesn't work if the RED initiates the connection over 3G
Fix [NUTM-4263]: [Access & Identity] [RED] DNS resolution stopped working for RED15 in transparent / split mode after updated to v9.4
Fix [NUTM-4332]: [Access & Identity] Vulnerabilities after deploying RED
Fix [NUTM-4336]: [Access & Identity] RED50 split DNS does not work properly in transparent split mode and static uplink
Fix [NUTM-4342]: [Access & Identity] Since update to 9.4 SSL VPN remote access not working with client with more than one TAP adapter
Fix [NUTM-4387]: [Access & Identity] WARN-070 notfication won't be send if "Drop packets from blocked hosts" is not used
Fix [NUTM-4390]: [Access & Identity] STAS: User network objects are not working as expected in several conditions due to AUA cache bug
Fix [NUTM-4424]: [Access & Identity] red_client fails to reconnect after HA takeover on server UTM
Fix [NUTM-4494]: [Access & Identity] red15: logread debug output on usb stick is circular
Fix [NUTM-4499]: [Access & Identity] [RED Provisioning] Disable RED if its not bound to UTM anymore to avoid push_config
Fix [NUTM-4527]: [Access & Identity] Disable TLS compression in IO::Socket::SSL
Fix [NUTM-4612]: [Access & Identity] Failover back from 3g fallback to WAN is not working
Fix [NUTM-4668]: [Access & Identity] IPv6 AUTO_INPUT table empty after update to 9.404
Fix [NUTM-3174]: [Basesystem, Network] It is not possible to start the webadmin GUI anymore
Fix [NUTM-1746]: [Basesystem] "Allowed networks for SNMP queries are missing" pop up after first time enabling SNMP
Fix [NUTM-3580]: [Basesystem] SNMPv2c traps contain wrong snmpTrapOID.0
Fix [NUTM-4576]: [Basesystem] SNMP MIB: change descriptors to be standard conformant, add NOTIFICATION-GROUPs
Fix [NUTM-4645]: [Confd, Email] character ">" or "<" for smarthost password will change to "&lt;"
Fix [NUTM-4159]: [Confd] name="FUNCTION_DENY (Zugriff verweigert beim Aufruf der Confd-Funktion 'trigger'.)
Fix [NUTM-3519]: [Email] S/MIME AES256 encrypted mails cannot be decrypted
Fix [NUTM-3856]: [Email] Update Sophos Outlook Add-in to 1.3.1
Fix [NUTM-3132]: [HA/Cluster] Additional address - Assigned to Node feature not working like expected
Fix [NUTM-4661]: [HA/Cluster] postgres database rebuild needs to trigger mdw and repctl
Fix [NUTM-1957]: [Network] 28457: Name resolution not working on HA Slave if BGP is configured
Fix [NUTM-1959]: [Network] 35541: IPFIX not working with SolarWinds
Fix [NUTM-3168]: [Network] IRQd not running - restarted (Value too large for defined data type)
Fix [NUTM-3169]: [Network] changing a bridge with enabled VLAN interface causes bridge to become disabled indefinitely
Fix [NUTM-3761]: [Network] Software UTM fails to complete booting process after updating to version 9.4
Fix [NUTM-4026]: [Network] MTU change on a VLAN interface leads to MTU change of the real interface
Fix [NUTM-3304]: [Release Management] nic-naming: Provide a fix for delayed 210r2 software support
Fix [NUTM-4660]: [Release Management] HyperV u2d hook for NUTM-3028 was not included in 9.404
Fix [NUTM-2059]: [WAF] Multi-threading race condition causes "AH01842: decrypt session failed, wrong passphrase?" errors
Fix [NUTM-4122]: [WAF] Issue with URL hardening
Fix [NUTM-4362]: [WAF] Creating AUTO_OUTPUT rules for all real webserver IPs in autoscaling group fails
Fix [NUTM-4385]: [WAF] Webserver Protection reporting doesn't work / no entries for WAF in reporting database
Fix [NUTM-4582]: [WebAdmin] Unable to select the WAN interface with the initial setup wizard of v9.4xx
Fix [NUTM-2418]: [Web] HTTP proxy core dump on confd
Fix [NUTM-3110]: [Web] Proceed button not working when authentication is set to browser for warn pages
Fix [NUTM-3404]: [Web] Unable to load YouTube when YouTube for schools is enabled
Fix [NUTM-3485]: [Web] HTTP Proxy profile matching doesn't work for DNS groups which contain IPv6 addresses
Fix [NUTM-3920]: [Web] Sandbox: cleaning up old data in TransactionLog on slave nodes raises postgres errors
Fix [NUTM-4053]: [Web] Unknown repeatingly log line: 2016:05:09-08:46:47 utm-1 [user:notice] "
Fix [NUTM-4141]: [Web] sandboxd should use upstream proxy
Fix [NUTM-4163]: [Web] Httpproxy EpollWorker segfault in strncmp () from /lib/libc.so.6
Fix [NUTM-4295]: [Web] STAS is not working as expected together with httproxy
Fix [NUTM-4381]: [Web] Malicious file with patience page does not give -3 message in http.log
Fix [NUTM-4412]: [Web] Policies tab under Web Procetion -> Web Filtering won't be displayed correctly
Fix [NUTM-4152]: [WiFi] RED15w not broadcasting TKIP networks
Fix [NUTM-4190]: [WiFi] SMC MAC filters aren't applied by local wifi
Fix [NUTM-4425]: [WiFi] awed unable to process connections timely
Fix [NUTM-4596]: [WiFi] Awed leak sockets leads to no more AP's are accepted

RPM packages contained:
client-openvpn-9.40-14.gada5e18.rb2.noarch.rpm
firmware-wifi-9400-0.230200226.g80f1105.rb8.i586.rpm
firmware-wifi-stable-9400-0.234966053.ge8e6d3b.rb4.i586.rpm
irqd-0.7.0-1.0.228416290.g7ef8e7e.rb4.i686.rpm
modauthnzaua-9.40-79.ge1b2593.rb2.i686.rpm
modsecurity2-2.7.4-277.gb6f5bdf.rb5.i686.rpm
perf-tools-3.12.48-0.233766410.gba768e5.rb4.i686.rpm
perl-IO-Socket-SSL-1.953-1.659.g2559319.rb8.noarch.rpm
red-firmware2-5031-0.235131781.g7987f42.rb1.noarch.rpm
red15-firmware-5031-0.235131857.g877fd69.rb3.noarch.rpm
sophos-wifi-0.1-1.0.230200323.gb9ecf2f.rb1.i686.rpm
ulogd-2.1.0-132.g5c62b7f.rb8.i686.rpm
ep-aua-9.40-28.gbdc3665.rb5.i686.rpm
ep-awed-9.40-51.g7997621.rb2.i686.rpm
ep-branding-ASG-afg-9.40-40.g8d42bae.rb4.noarch.rpm
ep-branding-ASG-ang-9.40-40.g8d42bae.rb4.noarch.rpm
ep-branding-ASG-asg-9.40-40.g8d42bae.rb4.noarch.rpm
ep-branding-ASG-atg-9.40-40.g8d42bae.rb4.noarch.rpm
ep-branding-ASG-aug-9.40-40.g8d42bae.rb4.noarch.rpm
ep-confd-9.40-693.g02eb320.i686.rpm
ep-confd-tools-9.40-651.g9244f52.rb11.i686.rpm
ep-endpoint-0.5-0.231441348.g608e799.rb4.i686.rpm
ep-ha-9.40-11.g2b0cc80.rb4.i686.rpm
ep-mdw-9.40-430.g6c953e6.rb9.i686.rpm
ep-notifier-9.40-11.ga2aa9a0.rb2.i686.rpm
ep-postgresql92-9.40-39.g8fd6d3f.rb2.i686.rpm
ep-red-9.40-14.gcc09a45.rb2.i686.rpm
ep-repctl-0.1-0.234283635.g8de5bc3.rb2.i686.rpm
ep-sandboxd-9.40-0.230949944.g3f3aef2.rb4.i686.rpm
ep-tools-9.40-1.gde2fb4c.rb2.i686.rpm
ep-utm-watchdog-9.40-5.g8e7d9f6.rb1.i686.rpm
ep-webadmin-9.40-632.g5c65d26.rb9.i686.rpm
ep-webadmin-contentmanager-9.40-39.gf509182.rb4.i686.rpm
ep-cloud-ec2-9.40-14.g764066d.rb2.i686.rpm
ep-chroot-dhcpc-9.40-2.gbc69780.rb7.noarch.rpm
ep-chroot-quagga-9.40-0.200137106.g6b2c195.rb9.noarch.rpm
ep-chroot-smtp-9.40-94.gd009606.rb2.i686.rpm
chroot-httpd-2.4.18-0.gaf88f5f.rb6.i686.rpm
chroot-reverseproxy-2.4.10-229.g9a46f65.rb2.i686.rpm
ep-httpproxy-9.40-343.g821fcb5.rb7.i686.rpm
quagga-chroot-0.99.23-336.gaff9cd8.rb9.i686.rpm
kernel-smp-3.12.48-0.233766410.gba768e5.rb6.i686.rpm
kernel-smp64-3.12.48-0.233766410.gba768e5.rb6.x86_64.rpm
ep-release-9.405-5.noarch.rpm



This thread was automatically locked due to age.
Parents

  • I'm using a Broadcom dual NIC card.  My External MTU is 576 and I can't change it to 1500 either, keeps reverting back to 576 after the save.  My UTM was working fine until this update.

  • in reply to PaulHolt

    PaulHolt said:

    I'm using a Broadcom dual NIC card.  My External MTU is 576 and I can't change it to 1500 either, keeps reverting back to 576 after the save.  My UTM was working fine until this update.

    I have the same.

    Upgraded to 9.405-5, and then noticed problems on one of my connections. 

    The troublesome one keeps reverting to a MTU of 576. (Took a while to figure that out.)

    The one affected with the 576 problem is a Interface with the type Ethernett, while my DSL PPPoE keeps it regular MTU. It only seems to be my uplink that's affected.

    Edit: Are we shure the update on "Fix [NUTM-2840]: [AWS] UTM ignores MTU sent by DHCP server" has not made us open to bad configured ISPs? I can't se "use ISP MTU" as a option under the interface settings. Using ISP MTU should always be a option, please do not make this a mandatory setting. For me it's the DHCP process that keeps setting the MTU to 576, but I have not been able to verify if it gets the MTU from my ISP or "makes it up".

    Edit 2: Changing the NIC (unplugging the cable from its original mediaconverter and using it on a different ISP) the MTU remains static. Towards the other ISP I'm also able to change the MTU, without it reverting. I'm suspecting that my ISP gives out a bad configured MTU. Will do a capture to check. Now I realy miss the optional use of ISP MTU. 

  • in reply to Vegard77Norway

    The PPPoE or PPPoA should show you the mtu value you are receiving from your ISP.

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

  • in reply to rfcat_vk

    rfcat_vk said:

    The PPPoE or PPPoA should show you the mtu value you are receiving from your ISP.

    My MTU problem is not with my PPPoE connection (PPPoE works with DHCP), it's with my regular DHCP Ethernet connection the MTU 576 is a challenge.

    Since I have tested the same NIC, with the same config against another DHCP server, there the MTU is static (and changable) my assumption is that its a bad configured MTU from one of my ISPs.  I need to confirm, but it looks like a bad implementation of the "Fix [NUTM-2840]: [AWS] UTM ignores MTU sent by DHCP server" that is the cause of the problems. Using MTU from a ISP should be a option, not mandatory, or at least possible to disable. (No such feature present, so a bad fix.)

    Edit: It's confirmed. Its my ISP giving me 576 as MTU in the DHCP Offer. (Wiresharked it up.) So it's a bad fix on 'Fix [NUTM-2840]: [AWS] UTM ignores MTU sent by DHCP server' making it mandatory to use a MTU size from the DHCP server when offered. It should be a option, or at least possible to disable.

  • in reply to Vegard77Norway

    I just did a tcpdump on my SG105 and confirmed this as well. The DHCP ACK is definitely passing DHCP option 26 (MTU) as 576. ISP is Comcast.

  • in reply to AdamKennedy

    AdamKennedy said:

    I just did a tcpdump on my SG105 and confirmed this as well. The DHCP ACK is definitely passing DHCP option 26 (MTU) as 576. ISP is Comcast.

    I ended up disabling the usage of the MTU information from the DHCP client. I wrote a short summary of it.

    https://community.sophos.com/products/unified-threat-management/f/52/t/79288

  • in reply to Vegard77Norway

    Hey, Vegard.

    Nice troubleshooting! While I agree that using ISP MTU should be available as an option, and not mandatory as it is, from my perspective this is more of a ISP issue then a Sophos issue, as your ISP should never be providing such a low MTU as a DHCP option. Still, if this is a commercial license, I suggest you open a support ticket with Sophos so they can be aware of the issues that option is causing due to misconfigured ISP routers and provide the option to enable it on demand. It  should be easy to implement, but they need to be aware so they can provided it as an option.

    As a matter of fact, everyone having issues should open a ticket. More people reporting the issue should get a fix available very soon.

    Regards - Giovani

  • in reply to giomoda

    giomoda said:

    .....

    While I agree that using ISP MTU should be available as an option, and not mandatory as it is, from my perspective this is more of a ISP issue then a Sophos issue, as your ISP should never be providing such a low MTU as a DHCP option. Still, if this is a commercial license, I suggest you open a support ticket with Sophos so they can be aware of the issues that option is causing due to misconfigured ISP routers and provide the option to enable it on demand. 

    ......

    Thanks for the feedback.
    1) This is a home free use license. Some of us using the home use license are more "tech savy" than others. I would assume there was a way of filing a ticket with a home use license. Who knows. One of us with such a license might comeacross something their QA department would like to look at before rolling into production with their paying customers.
    2) I would tend to agree that the MTU dialogue with the ISP could be possible. But .... My own ISP is not to bad. It's a Norwegian fiber based ISP company (Vikenfiber.no) that sell a product from a central provider called lyse.net. They have a pretty decent uptime. In short my only remarks about them so far has been exaggerated maintenance windows, and some hickups with their routing. With this malconfigured MTU setting in their DHCP Server I've been on the phone with their 1st level support three times, for what must accumulate to one hour pluss. I've gotten one SMS and voice mail (In Norwegian othervise I would link it on soundcloud for the laughs) stating that everything is right with their equipment. They always fall back on the fact that I use their homerouter in 'bridgemode' (to get a actual internett address, and not a lan address), thereby "disabling all their features, functions and services". Saturday they had no staff on above 1st level / servicedesk, today their "technical staff" has looked on this, agreed that is my fault and pushed that back down to the case operators on the first level. Trying to convince the person on their first level support that I actually get my IP address from them is hard enough. Becouse "In bridgemode everything is turned off, and nothing is slowing anything down". Even getting the person on the other side to acknowledge they do have a DHCP server is a challenge.
    To be honest... if my normally good ISP is this troublesome convincing they have a configuration fault, how hard will it be to convince a crappy one? 
    Lets just make this easy for everybody. We don't need to help them fix their stuff, if we can just ignore their settings. Then when they upgrade to something that actually uses that crappy MTU value they push out... it will be their problem.  I would prefer that they used real MTU values, not 576, but life is not perfect...  
Reply
  • in reply to giomoda

    giomoda said:

    .....

    While I agree that using ISP MTU should be available as an option, and not mandatory as it is, from my perspective this is more of a ISP issue then a Sophos issue, as your ISP should never be providing such a low MTU as a DHCP option. Still, if this is a commercial license, I suggest you open a support ticket with Sophos so they can be aware of the issues that option is causing due to misconfigured ISP routers and provide the option to enable it on demand. 

    ......

    Thanks for the feedback.
    1) This is a home free use license. Some of us using the home use license are more "tech savy" than others. I would assume there was a way of filing a ticket with a home use license. Who knows. One of us with such a license might comeacross something their QA department would like to look at before rolling into production with their paying customers.
    2) I would tend to agree that the MTU dialogue with the ISP could be possible. But .... My own ISP is not to bad. It's a Norwegian fiber based ISP company (Vikenfiber.no) that sell a product from a central provider called lyse.net. They have a pretty decent uptime. In short my only remarks about them so far has been exaggerated maintenance windows, and some hickups with their routing. With this malconfigured MTU setting in their DHCP Server I've been on the phone with their 1st level support three times, for what must accumulate to one hour pluss. I've gotten one SMS and voice mail (In Norwegian othervise I would link it on soundcloud for the laughs) stating that everything is right with their equipment. They always fall back on the fact that I use their homerouter in 'bridgemode' (to get a actual internett address, and not a lan address), thereby "disabling all their features, functions and services". Saturday they had no staff on above 1st level / servicedesk, today their "technical staff" has looked on this, agreed that is my fault and pushed that back down to the case operators on the first level. Trying to convince the person on their first level support that I actually get my IP address from them is hard enough. Becouse "In bridgemode everything is turned off, and nothing is slowing anything down". Even getting the person on the other side to acknowledge they do have a DHCP server is a challenge.
    To be honest... if my normally good ISP is this troublesome convincing they have a configuration fault, how hard will it be to convince a crappy one? 
    Lets just make this easy for everybody. We don't need to help them fix their stuff, if we can just ignore their settings. Then when they upgrade to something that actually uses that crappy MTU value they push out... it will be their problem.  I would prefer that they used real MTU values, not 576, but life is not perfect...  
Children
No Data
Unfiltered HTML