Guest User!

You are not Sophos Staff.

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

Issues with Home Edition Sophos XG

Works one day then not the next. You come here for help and you get answers that suggest the problem is always elsewhere.. like:

  • Your hardware is bad
  • your internet connection is bad.. to bad that's why I have 3 internet connections and this is supposed to failover..

Plus, if the hardware is bad, why did it work in other operating systems without issue? Why does ping work but no TCP connections?

If the rules are wrong, why does it work one day and not the next? Why does a reboot sometimes fix it sometimes breaks it?

Then I'm left in the dark in a proprietary Linux distribution with atrocious documentation.. hell. /var/log wasn't even followed.. so yeah Sophos let's do everything your own special way to get those billable hours

Been using Sophos XG for 3 years and my hardware is designed for this setup and now it is all a waste.



This thread was automatically locked due to age.
  • If you want still to look into this, its possible to reflect your issue. 

  • I reset to factory defaults..

    This will work for maybe a week or two..

    How can we ever find the issue since all solutions ever recommended by anyone is to blame anything other that Sophos XG?

  • Network issues are actually hard to troubleshoot if you do not have the experience to dig deeper into traffic flow. Who is actually pointing to other things? 

    And whats your actual issue? How do you see the issue and what did you do in the past to troubleshoot it? 

  • What really makes it hard to debug Software problems is a proprietary nonstandard Linux firewall with no documentation on the core or backend.. and a web interface that doesn't provide the information needed.. not to mention the install of Linux is seriously messy.. let's put everything in /tmp

    Been using Sophos XG for years and never had an issue.. ever.. 16 goes to 17 then 18.. and now nothing but problems.. but it is my ignorance?

    I can program c to connect to the tcpip stack.. I am acutely aware of how networking works..

  • There are certain tools to use, but as DPI started to introduce itself, it gets harder to debug compared to a tool, which was build 20 years ago. 

    Start with tcpdump, start with conntrack and look into the packet flow. It actually will give you everything you need to figure out, which part of the XG is causing this issue in no time. 

    With conntrack you quickly check all loaded policies. You check if the DPI is started etc. 

    Then check with tcpdump, what the actual packet flow is and which interfaces, IPs etc. are used. 

    If you have a multi WAN setup, SD-WAN is a new story. SD-WAN is something to get a packet as quickly as possible to destination, completely ignoring "the rules of stateful firewalling". SD-WAN PBR is something, which actually want to cause to use asymmetric routing. This can be reviewed within conntrack as well. 

    This should give you the needed information to get this fixed in no time. As well as --> Simply disable module to module and check, if this will fix the issue. Then enable more modules until you find the causing module.

    SFOS does not use /var/log instead /log/. So that is not that big of a difference. Logs are there, and documented: docs.sophos.com/.../LogFileDetails.html

  • Again, every answer you speak of in this incredibly "complicated" system.. is that the problem is elsewhere..

    It works now.. right now.. working..

    Why should that change?

  • I cannot help your issue, if you are not providing the needed answers. Thats the core problem right now. First you want tools to debug an issue, then you cannot follow those, because they are to complicated. 

    You can move to a vendor, which does TLS1.2 proxy etc. Those tools are easy to troubleshoot. You have problem with a proxy --> disable the proxy --> It works.

    A "next generation firewall" with implements like DPI, TLS1.3 decryption and SD-WAN are more complicated because the techniques used to protect such technologies are more complicated. 

  • Well we finally agree.. you can't help.. but it isn't for a lack of my cooperation.

    How is it a troubleshooting technique of a system to disable and bypass that very system?

    I can connect to the wifi on the hotspot and it definitely works.. bypassing the whole firewall but then the other links and failover don't work..

    Then you say to follow steps to troubleshoot.. but it is as if you are ignoring the fact that at this present time it is 100% functional.. it was made functional by a factory reset.

    Just like a week ago on the other post.. same problem.. same fix.. temporary solution.

    But if it works now, it can't be hardware or configuration- it has to be a software issue that is related to endurance and stability

  • You are not disable or bypass the entire system. You simply try to check, which component of the system is causing the issue. 

    Do not forget --> The system is more complicated as the destination of those systems are moving towards complicated systems. Look at TLS1.3 vs TLS1.2 and check, how to decrypt those system. TLS1.3 means the death of proxy system. And this means you cannot simply redirect a client request to a module and tell the system "please decrypt this and load the request". 

    What about the ISP? In your scenario: XG verify (currently) the ISP uptime by using Ping or other services. Most likely its Ping per default in your config. If the ping succeed, XG will consider this connection to be health and send packets. If the ISP is only responding to Ping but not tcp/ip packets (and those are different). Then you have a problem. 

    Its unlikely a hardware problem. Instead i can think of a mix of ISP and corrupted packets. 

    Check the packet flow of XG to see, what is actually going on. Those systems are complicated because of the technology coming up on the horizon. https://community.sophos.com/sophos-xg-firewall/f/recommended-reads/122357/life-of-a-packet---sophos-xg-v18-0

    To get to a conclusion: If the issue is present, you need to check, what the packet is actually doing. Then check if the packet are working as expected. Use SD-WAN for example to force one connection over another. I have a dual WAN connection with one (very instable ISP). If i expect an issue, i simply move to the other ISP and all problems are gone until the ISP get this fixed. 

  • Hi Jason,

    I'm sorry to hear that you’re having issues with your setup.

    To confirm, are you using the free Sophos Home XG edition or did you have a paid license? If it's the latter, I can help with following up with any Support cases you have raised with us.

    If it's the former, please be cooperative and respectful with our wonderful Community experts on the forums who are doing their best to help you in their spare time.

    I can also see that you have an ongoing discussion here with a number of pending troubleshooting suggestions: https://community.sophos.com/sophos-xg-firewall/f/discussions/128866/sophos-xg-basic-wan-routing-issues