Thread Info
  • State Verified Answer
  • +3 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Subscribers 32 subscribers
  • Views 41311 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

IPSec Site to Site VPN

Chris Backer

Hello everyone,

     I have a Sophos XG firewall and SonicWALL SOHO site to site VPN setup between those two firewalls. It connects up just fine and stays connected for hours but randomly it will go down and I have to go manually connect it back up. Luckily it's not a super important VPN but still I don't understand why it randomly goes down. 

I do have the latest firmware installed on both the SonicWALL and the Sophos XG. 

I have changed the dead peer detection on and off both on the SonicWALL and the Sophos XG to see if that makes a difference but it does not matter if that is on or off. Does it matter on the type of encryption I am using between the two? Is there a known issue with this that I am missing?

Any help would be appreciated. 

Thank you. 



This thread was automatically locked due to age.
Parents
  • 0

    Hey so I just did some serious troubleshooting with similar issues. I wrote this blog detailing my escapades and the solution. 

     

    What I recommend based on what you are seeing. 

    I am not super familiar with Sonicwall but if you can change DPD to initiate or disconnect set it to one of those. 

    Set the Sophos side to the other. If you do not have this setting on the Sonicwall set the Sophos DPD to disconnect

    The reason the tunnels are probably not coming up is because there is a bug where the tunnels will try and re-initiate without fully tearing down the tunnel. This creates an issue where the tunnel never fully comes back up. 

    Sophos will recommend that one side of the tunnel is a responder and the other side Initiates (not talking about DPD anymore). However, this does not help if you want either side to be able to initiate. I have stable tunnels which are both have the Gateway mode set to Initiate and it works AS LONG AS the DPD is set as I mentioned above. 

  • 0 in reply to Joe Plunkett

    My problem was that I had a PFS Group (DH Group) set on the Sophos on Phase 2 when the SonicWALL didn't have that option. So I had to set it to None on the Sophos. 

    Somehow I missed that when Initially setting this up. Not sure if that will help anyone or not if they are having the same issue. 

    Thank you for everyone's replies!

  • +3 in reply to Chris Backer

    On a side note, the Sophos IPSec site to site VPN's experience some extreme throughput degradation when PFS is enabled.  We have a Sonicwall at our main office, and Sophos XG firewalls at branch offices that connect through site to site IPSec VPN.  With our WAN connection speeds, we couldn't explain our poor VPN performance (transfer speeds across tunnel were only around 200 KB/s).  I read a forum post that PFS is known to cause performance issues, so I tried setting it to none for both VPN configs.  To my surprise the transfer speed went from 200 KB/s all the way to 2 MB/s, the only difference was PFS being disabled.  Please note the speed measurements are from Windows SMB file transfer, so bytes per second.  I just wanted to make everyone aware that (at least with using v16.0.5 MR 6 to Sonicwall) using PFS for better security greatly hinders performance, perhaps that is not a big deal for your specific use case, but we needed all the throughput we could possibly get.  Of course, I encourage you to test how PFS behaves in your own environment as decreasing security settings is never recommended.

     

    The other thing I wanted to mention is SHA256 (used in Phase 2) can cause a mismatch between Sophos XG IPSec VPN and Sonicwall.  What happens is the tunnel establishes and shows connected/green, but because of a slight difference the computations are different on both sides and all traffic is dropped, you will not be able to ping anything across the tunnel i.e..  It is a challenging issue to troubleshoot because you wouldn't think to look at the hashing algorithm being used, I believe this issue may also carry over to Fortigate units.  I mention this because I hope it helps someone else that runs into the problem.  After SHA256 caused this issue, I found SHA384 worked just fine for Phase 2.

Reply
  • +3 in reply to Chris Backer

    On a side note, the Sophos IPSec site to site VPN's experience some extreme throughput degradation when PFS is enabled.  We have a Sonicwall at our main office, and Sophos XG firewalls at branch offices that connect through site to site IPSec VPN.  With our WAN connection speeds, we couldn't explain our poor VPN performance (transfer speeds across tunnel were only around 200 KB/s).  I read a forum post that PFS is known to cause performance issues, so I tried setting it to none for both VPN configs.  To my surprise the transfer speed went from 200 KB/s all the way to 2 MB/s, the only difference was PFS being disabled.  Please note the speed measurements are from Windows SMB file transfer, so bytes per second.  I just wanted to make everyone aware that (at least with using v16.0.5 MR 6 to Sonicwall) using PFS for better security greatly hinders performance, perhaps that is not a big deal for your specific use case, but we needed all the throughput we could possibly get.  Of course, I encourage you to test how PFS behaves in your own environment as decreasing security settings is never recommended.

     

    The other thing I wanted to mention is SHA256 (used in Phase 2) can cause a mismatch between Sophos XG IPSec VPN and Sonicwall.  What happens is the tunnel establishes and shows connected/green, but because of a slight difference the computations are different on both sides and all traffic is dropped, you will not be able to ping anything across the tunnel i.e..  It is a challenging issue to troubleshoot because you wouldn't think to look at the hashing algorithm being used, I believe this issue may also carry over to Fortigate units.  I mention this because I hope it helps someone else that runs into the problem.  After SHA256 caused this issue, I found SHA384 worked just fine for Phase 2.

Children
  • 0 in reply to GushyJoseph

    Interesting. Right now there isn't a lot of file transferring happening between the two sites so i may leave PFS enabled for now. 

     

    I am using AES256 and SHA1 betweeen the Sophos and the SonicWALL and the site to site VPN hasn't gone down since last Friday. Good to know though about SHA256. 

  • 0 in reply to Chris Backer

    Its really a nightmare!!

    We are running about 800 VPNs tunnels between Sophos XG and several Sonicwall gateways all around the world. We have several support session with the Sophos Support and Global Escalation Team --> currently there is no solution for our issues.

    We are running 16.0.8 MR8 since last week.

    With 16.0.8 MR8 we have IPSec issues with multiple subnets on both sites - we tried everything to get a stable configuration with IKEv1 and different IPSec policys 3DES/SHA-1/None, AES256/SHA2-256/DH2 or DH5, same SA lfetime or smaller in phase2.

    The Support have advise us to install the new 17.0.5 MR5 - we started the update... (I didn´t do this again without a test-environment!)

    Issues:
    - IKEv1 with multiple subnets on both sites --> workaround switch about 800 tunnels to IKEv2 (would be a long night!)
    ... after we have everything migrated, we thought that we have it stable now... next morning 50% of tunnels were down!

    - WebGUI will hang and the appliance will get unresponsable --> failover to the slave appliance.
    ... All IPSec connections must be actived manually cause the failover doesn´t switch the status (enabled/disabled)...

    Support have tried to find out the root cause for our problems and tried some fixes.

    - WebGUI becomes serveral times unresponsable... we must had restarted the IPSec connections over 7 days.
    ...

    Today we decided to change the plattform to SG. Today we have configured everything from scatch new - we are stable but running an old plattform now... very poor!!!

     .-(

  • 0 in reply to Sven R

    Sven, 

    Check out the link I shared in a previous post on this thread. 

    The other week I spent a week working with Sophos and the escalation team to sort all these issues. I was seeing all the same stuff. 

    Long story short, in V17 they rebuilt the entire VPN daemon. This meant that settings on V16 which had worked, sent my firewalls into a constant loop trying to establish vpn connections. I would recommend turning off non vital tunnels for an upgrade to 17.x. Doing that will fix the GUI hanging issue. 

    I would be willing to bet most of your issues are related to DPD and keying times. There are detailed settings in the link I shared, but basically make sure one side of the tunnel has DPD set to disconnect, ensure Phase 1 is longer than phase 2.  Turning off PFS (not ideal) can solve some rekeying issues. 

    I do have XG v17 tunnels with stable connections to Sonic Walls but it took some work.