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

XG troubled waters ...

I have been struggling since May trying to set up a Sophos solution including XG firewalls, Web Gateways and Mail Gateway. I will discuss here our last attempt to have XG work.

First we have a LAB on which we installed two XG210, upgraded last week to v17.  In between them a Cisco 3560 switch, layer 3. And a Cisco RV325 router. The way it is setup, all WAN addresses and routes are much the same as real life conditions (production).

Both firewalls (two sites) have very similar rules, Domain controllers, SQL Servers, Files Servers, WEB Gateway, Site2Site VPN, et.c.  Bla, bla, bla.  Classic for small businesses.  Except one firewall have 3 extra rules for SMTP.  Around 60 rules total.

I’ve connected both firewalls (both sites) last Friday at both locations and it failed yet again.  Last time, SMTP traffic would not work and VPN would disconnect every 15 minutes.  This time, SMTP seems to flow.  But most importantly, I found one reliable way to reproduce VPN failure:  whenever https traffic passes through. 

 

I repeat. Whenever https traffic passes through, VPN falls.  I've just written it.  It read myself, and I cannot believe it.

 

I received around 1000 notifications of VPN ups and downs during the weekend.  The following hold throughout the week-end :

All of the time …(meaning without interruptions)

Teamviewer sessions were alive and connected to management workstations at both sites, behind XG210s.  Meaning I could access both sites, VPN down, or not.  Which means Teamviewer VPNs never failed.

Teamviewer sessions would also work well from my home to both locations.

Management workstations at both sites would ping the WAN addresses of both firewalls (port 2).  And anything in between.

Management workstations had access to Cisco RV325 router's https webconsole located between both firewalls' WAN port.  I.e. A non private, valid IP adresse.

Firewalls would ping the WAN address of one another.  And anything in between. ISPs routers for example.  All of the time.  VPN down or not.

Any attempt to access any HTTPS WEB page on the other site (i.e. behind the firewall through the VPN), no matter on what appliance or server’s portal, would crash the VPN instantaneously.

When the VPN is dead, one WEBconsole shows the VPN is still connected, while the other one shows it’s dead.  It was like this most of the time.

Any time the VPN was down, disconnecting the “connection” and reconnecting it would make it work again.  Instantaneously.  On any firewall whether the connection is up or down.  Up until HTTPS traffic flows.

Home TeamViewer sessions never failed.  (I.e. Not from any of both sites, but from a third location/site.)

 

Most of the time …

Rebooting the firewall would not reconnect the site to site VPN.

Connection and reconnection had to be done manually.

Or maybe some other device generated https traffic before I had a chance to access Sophos webconsoles.

 

Sometime …

Remote client VPN (from home) would seldom fail.  But did not seem to have any correlation with site-to-site VPN.

Firewalls WEBConsole would freeze sometime.

When this happens, I could connect via SSH, and SSH sessions would show items (i.e. would show telnet interface), but no command would work.  Like “6” which is “reboot”.

It is impossible, for example, to restart the firewall.

It takes from minutes to hours before it becomes responsive again.

Pull out power cord would clean it.

I wish I could have tested with the serial interface.

  

What I have tested meanwhile …

HTTPS connections that all failed.  From site A to site B.  And from site B to site A.

I killed The VPN setup and recreated it many times, and played with these parameters:

Local ID in DNS.

Local ID in IP Address.

DefaultHeadOffice 

Defaultprofile

DefaultBranchOffice

Gateway type “Initiate the Connection”.

Gateway type “Respond Only”.

Et.c.

I also just let both VPN running by themselves not trying to open any form of sessions.  Just allowing pings.

Thousands of mail status will show that VPN dies every 15 minutes or so.  Because OSes and other stuffs attempt https traffic too.

But when this happens (i.e. I have no session open whatsoever) VPNs will eventually reconnect.

But then, they will die again 15 minutes later.

  

What I have tested afterward …

Checkpoint’s firewalls are back in production like they have been since the early 1990s. (Virtual VMs). Same WAN dresses and same networking in general.  Connected to same Cisco and/or ISP routers.

Teamviewer VPNs.  Never failed.

Some cloud VPNs worked as well.

Could not find any other thing that failed.

  

In a nutshell,

HTTPS traffic coming from, or to, the “VPN” zone will kill the VPN.

There may be other ways to kill the VPN.

 

So.  What it is Sophos can’t do VPN ?

 

I contacted Sophos regarding this.  In my head, it should have press the "Pannic Button" in the development room.  But not really apparently.

 

Paul Jr Robitaille



This thread was automatically locked due to age.
Parents
  • Few things to try:

    1. Switch off DoS protection

    2. Try v16 firmware

    3. Try to use IPSEC for site to site connectivity

  • Hello

     

    Thanks for your feedback.

    1. I will try this later this week.

    2. The reason why we waited for v17 was that v16 behaved like this.  So' I already know HTTPS traffic fails on v16 as well.

    3. I was on the impression Sophos VPNs were already IPSEC.

     

  • Ok  Some improvements ...

    Sophos tech support asked me to change some parameters in some "IPsec Profiles".  Essentially, "DefaultHeadOffice" and "DefaultBranchOffice" are not the same for all parameters as out of the box. Go figure why.  Both are meant to work together after all. We modified to this : 

    Key Negotiation Tries was set to "0" (infinite).  "Key Life" & "IKEv2" parameters were also adjusted.  Things became far more stable.  Then I noticed an IKEv2 "Default Profile" was available.  I decided to give it a try.  It is new to v17, if I am not wrong.  I cloned the default IKEv2 to this: 

    The only thing changed to default "IKEv2" profile is the "Key Negotiation Tries" parameter I set to "0" i.e. Infinite.  I applied this to both location.  With the only difference, that one site's VPN has "General Settings -> Gateway Type" parameter set to "Initiate Connection" while the other is set to "Respond Only".

Reply
  • Ok  Some improvements ...

    Sophos tech support asked me to change some parameters in some "IPsec Profiles".  Essentially, "DefaultHeadOffice" and "DefaultBranchOffice" are not the same for all parameters as out of the box. Go figure why.  Both are meant to work together after all. We modified to this : 

    Key Negotiation Tries was set to "0" (infinite).  "Key Life" & "IKEv2" parameters were also adjusted.  Things became far more stable.  Then I noticed an IKEv2 "Default Profile" was available.  I decided to give it a try.  It is new to v17, if I am not wrong.  I cloned the default IKEv2 to this: 

    The only thing changed to default "IKEv2" profile is the "Key Negotiation Tries" parameter I set to "0" i.e. Infinite.  I applied this to both location.  With the only difference, that one site's VPN has "General Settings -> Gateway Type" parameter set to "Initiate Connection" while the other is set to "Respond Only".

Children
No Data