All of a sudden many FW Rule 60001 in FW log

ICMP type 11 = Time exceeded.

The 216.58.192.238 address is some Google address and could really be anything. Cannot really help you any further. If everything still works as excepted you could configure ICMP traffic to not LOG it's entries.

Hi Chrish,

The UTM cannot forward traffic that is sent to a Masqueraded WAN IP address unless it was requested by a client behind the UTM, or there is a NAT rule to redirect the traffic to an internal server (with the exception of services running on the UTM itself). If a packet arrives and is not for one of the UTM's services, and it is not part of an established connection, and there is no NAT rule for it, it will be dropped as fwrule 60001.

Refer the KBA here.

Thanks

Thanks.

I read that KB as part of my initial investigation but couldn't figure out what Google traffic would be hitting my WAN IP without it being requested by an internal IP.  That said, I'm using Google's DNS server's 8.8.8.8 and 8.8.4.4 as well as using an internal DNS server for local resolution.  I also use Chrome as my primary browser and have a number of Chromecast's in my environment, so plenty of Google stuff happening inside my network, but all that would be initiating the request from internally.

I would mention that occasionally YouTube and other Google services seem to take a long time to load (read: resolve) and maybe this FW drops are indicative of a larger issue than just slow name resolution.  Maybe the FW is thinking something is up with the packets and actually dropping a handful.  Again, it appears intermittent and shows up in the network as occasional slowness which I understand is hard to quantify but thought I would at least mention it.

After further review, most of the DROPs were as a result of recent changes in how UTM deals MTU DHCP messages from many providers.  Apparently mine, and many other ISPs send a bogus MTU size which gets set automatically on your WAN interface.  My MTU was being set to 576 which corresponds to length="576" in my FW logs and for one reason or another being dropped by the FW.

It appears in UTM 9.407-3 an additional option was put in place which allows you to disable automatically accepting the MTU size from your ISP and allowing you to set it manually to the actually MTU, in my case 1500, within the advanced settings within the interface configuration section of UTM.  Once I made the change in the UTM and set my MTU back to 1500, a large number of drops went away, specifically the ones that I showed which started the thread, and the slow behavior also improved.

 https://community.sophos.com/products/unified-threat-management/f/hardware-installation-up2date-licensing/80641/sophos-utm-9-407-3-released

As twister5800 wrote:

----

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! :-)

----

Chris' solution works, but I would do the following instead:

Find the REF_ of the Interface object named, for example, WAN (change ethernet to pppoe, pppoa or other if the following returns no result):

cc get_object_by_name interface ethernet WAN |grep \'ref\'

Say that returned REF_IntEthWan:

cc change_object REF_IntEthWan mtu_auto_discovery 0

If that returns REF_IntEthWan, the change was successful.  Then change the MTU to 1500 in WebAdmin.

Cheers - Bob

Hi Bob, you know that I don't know UTM internals, so I am reluctant to challenge here, but...

I expect MTU AutoDiscovery to mean that UTM helps determine the maximum MTU on a path between two nodes, by using a negotiating process that includes sending some packets with the do-not-fragment bit set and then interpretating response packets.   I forget how the algorithm works in detail, but it is something that one usually wants to be enabled.

Are you sure that you have the right parameter keyword for this situation?

You do not show port numbers or TCP Flags, but I think they should have been in the log detail.   I have investigated similar symptoms, and this is what I learned:

A normal TCP disconnect involves a packet exchange.   One end says goodbye and then the other end acknowledges the goodbye.   UTM has better things to do than to wait around for the confirmation, so it drops the connection.   They when the reply arrives, the packet is not associated with an active session, so the packet is blocked. 

Google is not doing anything wrong, it is just an anomaly of UTM's performance optimizations.   I think you will see FIN or RST in the TCP Flags to confirm this scenario.  Additionally, the source port indicates that it is a server you would typically utilize, such as TCP  80, TCP 443, or UDP 53.

On the other hand, I do recommend blocking UDP 443 in both directions, to prevent Chrome from bypassing your web proxy using its QUIC protocol.

You are right about the MTU negotiation in IPsec VPNs, but this is not the same thing.  This is the DHCP Client receiving the assigned MTU from the ISP.  The UTM shouldn't need to correct the ISP, but some of them are idiots.

Cheers - Bob