Forced to restart UTM

Hello everyone.  Thought I would update you on this issue, it's been a few months.  I need to eat my words here.  The Sophos UTM is NOT a piece of crap, this issue was my cable internet service.  I actually took my cable service outside my home and removed the switch going to televisions and installed a single line coupler. So the only thing connected to my service was my Cable internet modem.  Guess what, the problems went away.

So this issue was due to my Cable modem going offline.  By the time I would check things the modem would appear to be online, but the Sophos UTM didn't automatically recover.  It had to be restarted.  I have since moved to a new home and have a fiber based internet service that is working flawlessly on the same hardware.  No issues even with what we thought were problematic NICs.  Thanks for all the input.  Hope this helps someone.

Frustrating issue.  I had even had the Cable people out to troubleshoot and replace my modem...  They couldn't help me..  In the end I had to do it myself.  Yeesh....

If you can, replace your modem with a personally owned modem.  And if you live in the states, you will save a few bucks because they most likely charge you for that cable modem per month.  The only down side with owning your own cable modem is that the Cable Companies have a conspiracy with the Cable Modem Companies to not include RJ11 phone ports on the public cable modems and only install them on the cable modems they sale to the Cable Companies.  However, I fixed their band wagon again and went with Ooma.

In addition, you should place the cable modem where you can see it.  My cable modem is sitting on top of my racked Cisco equipment in which I can see the lights.  In addition, Ooma tells me right away the cable is down because it is flashing red all over or the headset phone will state NO VPN if the cable modem is in synch but there is some other problem such as DHCP or other carrier problems outside the neighborhood concentrator or whatever infrastructure they now have in place.    That same problem happened to me last week and it was a simple fix of power cycling the cable modem.  Since then, it has been up with little to no line errors.

I'd like to know if this intel crash is ever going to get fixed. Its super annoying having to turn off hardware offloading at the command line every time i reboot the thing for updates etc. Is there a reliable way to schedule these commands after boot?

I'd like to know if this intel crash is ever going to get fixed.

Me too. I'm holding at version 9.113-1 because of this.

Not wishing this issue on those with paid support but I do wish there were more folks with paid support complaining about this since they don't want to hear from us free loading Home users [:D]

I had an interesting experience with the Intel e1000 nic recently.  Anytime I would put some data through the interface it would go offline for a few seconds before automatically recovering..  I noticed these log entries in "kernel".  I moved to a non-intel nic and things have been fine.

2015:01:22-11:57:58 tylerutm kernel: [613269.804434] e1000e 0000:00:19.0 eth1: Detected Hardware Unit Hang:

2015:01:22-11:57:58 tylerutm kernel: [613269.804434]   TDH                  

2015:01:22-11:57:58 tylerutm kernel: [613269.804434]   TDT                  

2015:01:22-11:57:58 tylerutm kernel: [613269.804434]   next_to_use          

2015:01:22-11:57:58 tylerutm kernel: [613269.804434]   next_to_clean        

2015:01:22-11:57:58 tylerutm kernel: [613269.804434] buffer_info[next_to_clean]:

2015:01:22-11:57:58 tylerutm kernel: [613269.804434]   time_stamp           

2015:01:22-11:57:58 tylerutm kernel: [613269.804434]   next_to_watch        

2015:01:22-11:57:58 tylerutm kernel: [613269.804434]   jiffies              

2015:01:22-11:57:58 tylerutm kernel: [613269.804434]   next_to_watch.status 

2015:01:22-11:57:58 tylerutm kernel: [613269.804434] MAC Status             

2015:01:22-11:57:58 tylerutm kernel: [613269.804434] PHY Status             

2015:01:22-11:57:58 tylerutm kernel: [613269.804434] PHY 1000BASE-T Status  

2015:01:22-11:57:58 tylerutm kernel: [613269.804434] PHY Extended Status    

2015:01:22-11:57:58 tylerutm kernel: [613269.804434] PCI Status             

2015:01:22-11:58:00 tylerutm kernel: [613271.804451] e1000e 0000:00:19.0 eth1: Detected Hardware Unit Hang:

2015:01:22-11:58:00 tylerutm kernel: [613271.804451]   TDH                  

2015:01:22-11:58:00 tylerutm kernel: [613271.804451]   TDT                  

2015:01:22-11:58:00 tylerutm kernel: [613271.804451]   next_to_use          

2015:01:22-11:58:00 tylerutm kernel: [613271.804451]   next_to_clean        

2015:01:22-11:58:00 tylerutm kernel: [613271.804451] buffer_info[next_to_clean]:

2015:01:22-11:58:00 tylerutm kernel: [613271.804451]   time_stamp           

2015:01:22-11:58:00 tylerutm kernel: [613271.804451]   next_to_watch        

2015:01:22-11:58:00 tylerutm kernel: [613271.804451]   jiffies              

2015:01:22-11:58:00 tylerutm kernel: [613271.804451]   next_to_watch.status 

2015:01:22-11:58:00 tylerutm kernel: [613271.804451] MAC Status             

2015:01:22-11:58:00 tylerutm kernel: [613271.804451] PHY Status             

2015:01:22-11:58:00 tylerutm kernel: [613271.804451] PHY 1000BASE-T Status  

2015:01:22-11:58:00 tylerutm kernel: [613271.804451] PHY Extended Status    

2015:01:22-11:58:00 tylerutm kernel: [613271.804451] PCI Status             

2015:01:22-11:58:02 tylerutm kernel: [613273.804472] e1000e 0000:00:19.0 eth1: Detected Hardware Unit Hang:

2015:01:22-11:58:02 tylerutm kernel: [613273.804472]   TDH                  

2015:01:22-11:58:02 tylerutm kernel: [613273.804472]   TDT                  

2015:01:22-11:58:02 tylerutm kernel: [613273.804472]   next_to_use          

2015:01:22-11:58:02 tylerutm kernel: [613273.804472]   next_to_clean        

2015:01:22-11:58:02 tylerutm kernel: [613273.804472] buffer_info[next_to_clean]:

2015:01:22-11:58:02 tylerutm kernel: [613273.804472]   time_stamp           

2015:01:22-11:58:02 tylerutm kernel: [613273.804472]   next_to_watch        

2015:01:22-11:58:02 tylerutm kernel: [613273.804472]   jiffies              

2015:01:22-11:58:02 tylerutm kernel: [613273.804472]   next_to_watch.status 

2015:01:22-11:58:02 tylerutm kernel: [613273.804472] MAC Status             

2015:01:22-11:58:02 tylerutm kernel: [613273.804472] PHY Status             

2015:01:22-11:58:02 tylerutm kernel: [613273.804472] PHY 1000BASE-T Status  

2015:01:22-11:58:02 tylerutm kernel: [613273.804472] PHY Extended Status    

2015:01:22-11:58:02 tylerutm kernel: [613273.804472] PCI Status             

2015:01:22-11:58:04 tylerutm kernel: [613275.804035] e1000e 0000:00:19.0 eth1: Reset adapter unexpectedly

2015:01:22-11:58:07 tylerutm kernel: [613279.408875] e1000e: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

I'm seeing the same Log entries with my VM with e1000 (not e1000e). But i did not noted any outage?!

you both have the infamous intel driver issue, you need to disable offloads, i had this problem and opened a thread as it seems this won't be solved anytime soon:

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

as to how to make that change permanent across restarts that's another issue completely

there is a driver bug with certain intel nics.  There is a temporary workaround....
log into the mahcine at the shell as root then type the following two lines:
ethtool -K eth2 gro off
ethtool -K eth2 gso off
ethtool -K eth0 tso off

the driver issue is on Intel's end. All Linux distros are waiting on Intel to fix this.  The UTM appliances use e1000 series nics and do not have this issue.

I'm seeing the same Log entries with my VM with e1000 (not e1000e). But i did not noted any outage?!

If you're running ESXi, you should probably switch to the VMXNET3 drivers.

Barry