All of a sudden many FW Rule 60001 in FW log

Question

All of a sudden I'm seeing a lot of FW Rule 60001 in the FW log. 
 What used to be a very quiet FW is now very chatty with spikes of 60001 drops every 5-10 minutes. I haven't made any configuration changes. Any idea where I start to begin troubleshooting? 
 /var/log/packetfilter.log:2016:12:05-11:55:51 sophos ulogd[4400]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="00:17:10:93:fc:96" dstmac="00:0c:29:2a:92:30" srcip="216.58.192.238" dstip="###.##.###.###" proto="1" length="576" tos="0x00" prec="0x00" ttl="58" type="11" code="1" /var/log/packetfilter.log:2016:12:05-11:55:51 sophos ulogd[4400]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="00:17:10:93:fc:96" dstmac="00:0c:29:2a:92:30" srcip="216.58.192.238" dstip="###.##.###.###" proto="1" length="576" tos="0x00" prec="0x00" ttl="58" type="11" code="1" /var/log/packetfilter.log:2016:12:05-11:55:51 sophos ulogd[4400]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="00:17:10:93:fc:96" dstmac="00:0c:29:2a:92:30" srcip="216.58.192.238" dstip="###.##.###.###" proto="1" length="576" tos="0x00" prec="0x00" ttl="58" type="11" code="1" /var/log/packetfilter.log:2016:12:05-11:55:51 sophos ulogd[4400]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="00:17:10:93:fc:96" dstmac="00:0c:29:2a:92:30" srcip="216.58.192.238" dstip="###.##.###.###" proto="1" length="576" tos="0x00" prec="0x00" ttl="58" type="11" code="1" /var/log/packetfilter.log:2016:12:05-11:55:51 sophos ulogd[4400]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="00:17:10:93:fc:96" dstmac="00:0c:29:2a:92:30" srcip="216.58.192.238" dstip="###.##.###.###" proto="1" length="576" tos="0x00" prec="0x00" ttl="58" type="11" code="1" /var/log/packetfilter.log:2016:12:05-11:55:52 sophos ulogd[4400]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="00:17:10:93:fc:96" dstmac="00:0c:29:2a:92:30" srcip="64.4.54.253" dstip="###.##.###.###" proto="1" length="576" tos="0x00" prec="0x00" ttl="102" type="11" code="1" /var/log/packetfilter.log:2016:12:05-11:55:53 sophos ulogd[4400]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="00:17:10:93:fc:96" dstmac="00:0c:29:2a:92:30" srcip="216.58.192.238" dstip="###.##.###.###" proto="1" length="576" tos="0x00" prec="0x00" ttl="58" type="11" code="1" /var/log/packetfilter.log:2016:12:05-11:55:55 sophos ulogd[4400]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth1" srcmac="00:17:10:93:fc:96" dstmac="00:0c:29:2a:92:30" srcip="216.58.192.238" dstip="###.##.###.###" proto="1" length="576" tos="0x00" prec="0x00" ttl="58" type="11" code="1"

Chris Sang · Answer

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

DouglasFoster · Answer

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.