Release of v17 MR-2?

Just a quick update. I've been working with the GES team, but so far no changes. I was able to upgrade to MR3 and they got the tunnel to establish. It ran for almost a week and then started disconnecting every few hours. High availability completely breaks the tunnel.

The thing that still seems to work, even though it shouldn't, is that if I switch the ipsec profile from Main Mode to Aggressive Mode the tunnel becomes more stable and will only disconnect about once a day rather than every few hours. This is strange because the ASA on the other end is set to Main Mode, and the vpn profile is not even supposed to be compatible with Aggressive Mode. It actually makes the selection list on tunnel profile blank. So this appears to be a definite bug. We're discussing switching back to Cisco. This issue has become a deal breaker for us.

Anyone else had any luck?

We're in the same boat.  Not an ASA but connecting to a Cisco Router at HQ.   Disconnects multiple times a day.  In our case the tunnel loses some of it's SA's that get established. Out of 9 SA's  that are part of the tunnel only one or two show green in the vpn connection and the site goes down. A reconnect will re-establish it, but what a pain in the butt. 

If anyone as a rock solid VPN connection to  a cisco device I would love to know what configuration you're using.   

-Scott

ok, So loaded up MR-5 last night on my XG. After the XG rebooted (after it's update was complete), my vpn tunnel did not successfully come back up all the way. I still had some SA's that were red and the tunnel was not fully up.  Now to be fair,  this was right after the update was applied and perhaps it was busy doing other things, but that tunnel should of come up "clean and green" after the reboot.    So I had to manually disconnect and reconnect my tunnel after the reboot from the firmware upgrade.

That being said, we're no longer seeing all those "Invalid SPI" error messages that we used to either.   So I've turned on debugging for strongswan in case the SA's dont re-establish themselves again.    

We'll see what happens.

-Scott

Thanks for sharing, I have a suspicion the IPSec VPN will be stable by MR 6.  I will definitely report my findings with MR 5 and test as IPSec VPN much as possible, but with all the issues reported it may just take a couple of updates to work everything out.  We are still waiting to hear how MR 5 does before considering updating any productions units to v17 from 16.5.

FYI.....Was just made aware of this.  --> https://community.sophos.com/kb/en-us/128175

Totally not stable on MR6. I've been waiting and not touching mine that was on MR3 because somehow it was finally just working. Tunnel fell apart Monday and it's been a nightmare since trying to keep it holding traffic. 

I did just make a change that I'm hoping will resolve it since the root issue is apparently having multiple child-sa's (according to some of the reports I've read here). I re-configured one of my subnets so that I could combine it with the other 3 in a /16 for my LAN instead of 4 /24's. Now there's just one /16 to /16 tunnel and I'm hoping it will work reliably. Supposed to head out traveling for 9 days and I'm the only one here that knows this @$^@$& firewall. Fingers crossed.

Still having issues with MR6 as well. Not even 2 Sophos XGs on MR6 are able to connect to each other with AES256 SHA256 etc. This is SUPER ANNOYING!!! Still got other tunnels to that just won't connect either for unknown reasons e.g. couldn't parse IKE message.

Personnaly, since 17.0.8 MR-8

we have lot's of deconnection with peer VPN :

2018-07-23 11:26:15 21[IKE] <Bailly_Courouble-1|4661> sending DPD request
2018-07-23 11:26:15 21[ENC] <Bailly_Courouble-1|4661> generating INFORMATIONAL_V1 request 172699093 [ HASH N(DPD) ]
2018-07-23 11:26:15 21[NET] <Bailly_Courouble-1|4661> sending packet: from XX.XX.XX.XX[500] to 185.39.XX.XX[500] (84 bytes)
2018-07-23 11:26:15 31[NET] <Bailly_Courouble-1|4661> received packet: from 185.39.XX.XX[500] to XX.XX.XX.XX[500] (84 bytes)
2018-07-23 11:26:15 31[ENC] <Bailly_Courouble-1|4661> parsed INFORMATIONAL_V1 request 2556777335 [ HASH N(DPD_ACK) ]
2018-07-23 11:26:17 23[IKE] <Bailly_Courouble-1|4661> closing CHILD_SA Bailly_Courouble-4{112} with SPIs cb297606_i (1182675 bytes) 091159cd_o (770213 bytes) and TS 10.10.15.0/24 === 172.16.87.0/24
2018-07-23 11:26:17 23[APP] <Bailly_Courouble-1|4661> [SSO] (sso_invoke_once) SSO is disabled.
2018-07-23 11:26:17 23[APP] <Bailly_Courouble-1|4661> [COP-UPDOWN] (ref_counting) ref_count: 1 to 0 -- down -- (10.10.15.0/24#172.16.87.0/24)
2018-07-23 11:26:17 23[APP] <Bailly_Courouble-1|4661> [COP-UPDOWN] (cop_updown_invoke_once) UID: 4661 Net: Local XX.XX.XX.XX Remote 185.39.XX.XX Connection: Bailly_Courouble Fullname:

Hello Bjoern

We had a Cisco RV325 router between our XG210 and the internet ...  Sophos and Cisco were mutually allergic.  Cisco's RV325 very basic setup was 1 WAN address, and 8 LAN addresses.  That's it , that's all.  For some reasons, the RV325 was re forwarding back pings (Dead Peer Detection) from the XG210.  XG210 would consequently not see the other end and was dropping connections.  All this time, any other devices on our networks would ping each other.  WAN and LAN thru and outside the VPN.  In XG210's diagnostic menu, Firewalls WAN were pinging each other !!!  Go figure why DPD were bouncing.

To make a long story short, Sophos support help me to put the WAN address directly into the Sophos XG210, allowing us to decommission the Cisco RV325.  He also helped me to setup the VoIP in such a way it would work with the WAN directly on the XG210.

I may have to put back a router one day ...  What I'm gonna do then, I do not know ...

On a positive note, latency felt from 60 ms in average down to 40 ms ...

Paul Jr

We are in August ... zzzzzzzzzzzzzzz

I still have yet to buy another XG firewall since a terrible VPN experience earlier this year. I continue to buy the other (software) products for customers though which I do like. Meraki seems like a much safer bet for firewalls. Sophos Rep, change my mind! Seeing the feature requests page, and some of the stuff that's lacking is just embarrassing.

We are 18 month late on the development.  v16, v17 have mostly been bug creation/fix so far, and minor cosmetic stuff.  We now have CASB, kind of, but I wonder how many XG users use it actually.  Would have been far more important to fix LDAP connection, Reporting, and all others things mentioned already too many times. 

The REAL problem I see is that major community contributors stopped posting. We see as many questions generated as before, but not many "experts" left to answer them.  SFOS 17.1.1 MR-1 so far is stable for us, but the pace at which development happens was a legitimate argument to look elsewhere.  We are stalled ...

Paul Jr 

We are 18 month late on the development.  v16, v17 have mostly been bug creation/fix so far, and minor cosmetic stuff.  We now have CASB, kind of, but I wonder how many XG users use it actually.  Would have been far more important to fix LDAP connection, Reporting, and all others things mentioned already too many times. 

The REAL problem I see is that major community contributors stopped posting. We see as many questions generated as before, but not many "experts" left to answer them.  SFOS 17.1.1 MR-1 so far is stable for us, but the pace at which development happens was a legitimate argument to look elsewhere.  We are stalled ...

Paul Jr 

Hi folks,

I think one of the biggest issues is the failure to perform QA completely on each release , just look at the latest UTM issues.

Don't get me wrong I am not downplaying the missing features. I must admit I have not yet compared v17.1.1 with my home user list of missing or faulty features.

Ian

I agree,

A while back the updates were coming thick and fast and with each brought new bugs and issues. I always find it would be difficult to fully QA every detail every time due to the expansive way we all configure, use and deploy the XG Firewalls (not excusing basic QA)

I have found many issues and work arounds through other users like you guys and some who no longer visit the forums and I haven't yet found Sophos Support that good at what they do.

I also need to upgrade my XG Firewall to a bigger one and I am stuck deciding whether to stay Sophos or reinvest in something else without the headaches. I have spend the best part of the last 2 years learning and configuring the current XG and I still find issues daily that frankly shouldn't happen.

STAS is a steaming pile of dog turd on a good day!

I truely hope some Sophos folk read this and reiterate to the development team they will lose many customers if the fail to raise the bar a bit.

There are things in the list that could be fixed very rapidly.  For example, NTP time services have been developed on all platforms on the planet a long time ago.  There is no need to re develop that code. It already exist everywhere !!! Same goes for DNS.  Same goes for a lot of things in the list.  I do not know how complicated it is to re code Stass however.  Symantec have  “DC Interface”  since Mathusalem that is very small as a service and works as intended.

What I do understand is that XG is a collection of services running on an hardened OS that Sophos have not developed.  They integrate and secure services mostly.  The rest is a WEB interface to cover it.  VPN is Strongswan (https://www.strongswan.org/) for example.

So ....  

Paul Jr

I hear you mate!

The XG was probably released about 2 years too early.

Seems Sophos lack direction....

Ian: Like your description of STAS :) Have your issues with STAS not yet been resolved?

I suspect many of us are in the same boat. Also need to upgrade hardware at the end of 2018. Stick with Sophos or move to Fortigate.

I have received good support from Sophos but at the cost of multiple international calls from Cape Town, South Africa to the UK. Sophos have toll free or local numbers for numerous countries but forgot that there is large continent called Africa.

It definitely does feel like the pace of development has slowed considerably.

envercpt said:

Have your issues with STAS not yet been resolved? 

STAS works well about 98.5% of the time - its the ones where a user logs on and gets the 10.255.0.1 pop up (me) when I am authenticating with AD fine.

Or when for no reason the XG stops authenticating me and either cuts me off or goes to NTLM - random and no reason why.

Stuff like that gets a little old and when you have a heap of users having to log off and back on to get a connection due to STAS having a cow its not a good thing.

STAS for us has been a bit of a PITA, but primarily for machines that have multiple users logging in during the day.  I have found the SSO client to work well.  It is unfortunate that the installer that Sophos wrote has so many bugs, it is practically uninstallable.  I actually wrote my own installer and pushed via a GPO.  All you need is Advanced Installer 15, the executable, add to the Installer project a registry entry HKLM-software-MS-Windows-CurrentVersion-Run.  Have the GPO itself put in the HKCU the ip of the sophos, and the domain name (the executable does not look at HKLM).  I abandoned STAS recently and am actually quite happy with the SSO client.  A few other issues with STAS:  1) if the db file gets too big on a DC, it can mess up authentication.  2) STAS can cause an loop lock from web traffic on a terminal server.  This issue I did not see until this latest version.  Yes, you can take measure to deal with a terminal server, but if for whatever reason you don't, might take a while to figure out just what is breaking authentication completely.  This I find inexcusable. 

SSO Client works fine for the most customer, who can build their script at their own.

The "Sophos" logon script is only a example but you are right, you can build your own GPO with the correct flags in registry etc.

Do you want to publish a How to: about this? I am quite sure, FloSupport is happy tp help you to update an KBA. 

manbearpig said:

 

Do you want to publish a How to: about this? I am quite sure, FloSupport is happy tp help you to update an KBA. 

 

I would be interested in seeing how you did this as well as I am losing faith in STAS and would like another way.