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

Sophos UTM 9.5 drops packets - how to debug?

Our UTM is dropping packets, and I have no idea why or what to do.

Here are the facts:

- pinging the UTM from our LAN works fine (no packet loss)
- pinging the web (8.8.8.8) from Sophos (via terminal) works fine (no packet loss)
- pinging the web (8.8.8.8) from LAN (where UTM is, obviously, our gateway) drops packets - some go through, some don't
- Sophos UTM CPU usage is low, and there should be plenty of resources to handle all requests

At this point I don't know what to do. I've tried disabling the AV, Web Protection, Webserver protections... ping packets are still dropped. Note - the pings are a symptom - people in our company report internet access to be running slow and unstable, so it's NOT just the ping packets themselves.

What should I do at this point? I've tried the old IT method of turning it off and on, but that didn't solve the problem.



This thread was automatically locked due to age.
Parents
  • Hi Mateusz,

    The best method is to sniff the packets on the interface level to see if the packets get lost  in the utm or in your lan.

    You can do this with tcpdump:  

    Sophos Firewall: How to monitor packet flow using the CLI

    https://community.sophos.com/kb/en-us/123567

    Put the trace file in the loginuser homedir and transfer it on your pc to analyze it with wireshark.

     

    Good luck!

    CS

  • I'll accept this answer, but I've done something "simpler". I've disconnected Sophos and connected my own laptop directly and did some pings then - packets were dropped just like before.

    Needless to say, it seems our ISP is having issues.

    It seems the PING command on Linux / Sophos works a bit differently than in Windows and won't immediately print information about dropped packets. I'm not entirely sure how that works. In Windows, if there are dropped packets, the output instantly shows it.

  • Are you using the web admin to ping?

    In most cases using the cli is much better to resolve problems with packets.

     

    CS

  • I was using the CLI to ping, yes.

    Anyway, the issue seems to be our ISP and my misunderstanding of how PING works on Linux. Like I wrote - the tool on Windows will show dropped packets instantly as they are timed out. On Linux the tool works a bit differently and you can only tell that there are issues after you stop the tool and look at the dropped packets statistic.

    In our case, I was wrong in my original post when I though pings OK when testing from the CLI. They weren't. In other words - there was packet loss regardless if the testing was being done from a machine in our LAN or the UTM. In fact, I validated it was our ISP by hooking my laptop directly to our ISP - in all cases there was packet loss.

    Anyway - thanks for the help. I'll keep in mind how the PING works in Linux for the future if the same issue ever shows up again. TCPDUMP is, of course, a more through analysis tool, but I don't think it really applies in this case - in this case the right tool is a phone-call to our ISP. ;)

Reply
  • I was using the CLI to ping, yes.

    Anyway, the issue seems to be our ISP and my misunderstanding of how PING works on Linux. Like I wrote - the tool on Windows will show dropped packets instantly as they are timed out. On Linux the tool works a bit differently and you can only tell that there are issues after you stop the tool and look at the dropped packets statistic.

    In our case, I was wrong in my original post when I though pings OK when testing from the CLI. They weren't. In other words - there was packet loss regardless if the testing was being done from a machine in our LAN or the UTM. In fact, I validated it was our ISP by hooking my laptop directly to our ISP - in all cases there was packet loss.

    Anyway - thanks for the help. I'll keep in mind how the PING works in Linux for the future if the same issue ever shows up again. TCPDUMP is, of course, a more through analysis tool, but I don't think it really applies in this case - in this case the right tool is a phone-call to our ISP. ;)

Children
No Data