Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 27 subscribers
  • Views 517 views
  • Users 0 members are here
Options
Suggested
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

XG135(s) locked up using IPSEC tunnel

Andy Denley

HI All, 

I have had 3 lock ups over the last 4 days from two different XG135's all connected via IPSEC. And the only way to resolve is to reboot the device. 

The reason I mention IPSEC tunnels is that  the only thing causing any load was over IPSEC. We are currently in lockdown and no one is onsite to generate any additional traffic. 

the two XG135's have 5 IPSEC tunnels configured in a mesh configuration with each other and the other remote devices are 2x XG125's, 1x fortigate and 1x Untangled Firewall. 

Its all been running fine since we implemented 6 months ago until the last few days and I suspected that it maybe a hardware issue until the second XG135 did the same thing. 

I cant see anything in the logs. And it only seems to happen when I pumping traffic down the IPSEC tunnel. 

Any troubleshooting hints here? Would love to get this sorted. 

Andy



This thread was automatically locked due to age.
  • 0

    Hello Andy,

    Thank you for contacting the Sophos Community.

    If you haven't open a case with support I would recommend you to open one and share the Case ID with me.

    Please confirm what Firmware version are you running 18.5 18.0 17.5?

    You would need to check the following logs:

    csc.log, applog.log, syslog.log, msync.log, and networkd.log and see if there’s any recent core-dump under /var/cores

    Check the Memory and CPU graph details under, you'd be looking for a gap in the graph. 

    Diagnostics >> System Graphs (Change the Live Graph to a time range that matches the last time the issue happened)

    If this is a recurrent issue you would need also Console output (might be hard for you to get since you mentioned there is nobody in the office)

    Note: Be sure that the computer in question does not go into Standby or Hibernate while logging.

    Using PuTTY, go to 'Session' - 'Logging.'
    Here, select "All session output', and set the file name to a folder and name for later retrieval.
    Configure the Serial connection to use the proper COM port on your PC and a Speed of 38400.
    Start the session, and log in to ensure it is all proper.
    Once logged in, you can leave it there or log out and leave the session at the password prompt. Either way, leave the session active and allow it to capture the output from the next reboot.
    Once that reboot occurs, you can end the Serial connection and provide the logs to support further investigation.

    Things you can try to mitigate this:

    Check if Firewall acceleration is enabled, if it is disable

    console> system firewall-acceleration show

    To disable run:

    console> system firewall-acceleration disable

    Try the following command as well

    console> set advanced-firewall tcp-selective-acknowledgement off

    And if you are not using RED devices, but the RED service is running try to disable it from 

    System Services >> RED 

    Regards,

  • 0 in reply to emmosophos

    Hi Emmanuel, 

    Case is: 04362138 

    Firmware is : SFOS 18.0.5 MR-5-Build586

    There are no cores under /var/cores

    Red is disabled. 

    These commands you want me to enter, what effect will they have to any existing traffic? 

    Also we are in lock down, so i cant get to site as readily as there is no one onsite to assist if the firewalls go down for this client. 

    I will arrange with the client to return to site and set this up and try and replicate the fault. 

    Regards,

    Andy

  • 0 in reply to Andy Denley

    Hello Andy,

    Thank you for the follow-up.

    You’ll notice some traffic will get dropped momentarily (while the Fastpath is offloaded, some users might not even notice however I would recommend you to run the command after hours or a few minutes before the day start.

    Regards,

  • 0

    Andy - Looks like your case is proceeding and a solution has been provided even though 1 unit appears to be bad.  Thanks for asking your question in the community, but always remember for break/fix issues - its best to reach directly out to support ASAP.  Calling in is the best option, and an engineer can begin assisting right away verses emailing and waiting for the case to be created and assigned.

    Thanks for being a Sophos customer.