Thread Info
  • State Suggested Answer
  • +4 person also asked this people also asked this
  • Locked Locked
  • Replies 75 replies
  • Answers 6 answers
  • Subscribers 59 subscribers
  • Views 20585 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

Version 19.0.0GA Breaking IPSEC VPN's

Jeremy Thomas

We have 20+ Xg and XGS's deployed. We started pushing out the mentioned version updating from 18.5.3 MR-3 Build 408. The first 2 devices we updated had all kinds of VPN issues. Users could connect but the connection speed was garbage (less than 1mbps down). Was on the phone with support for over an hour. Finally they came back and said "after conferring with his colleagues there are issues with Version 19 we recommend you rollback". We did this and all the VPN issues were resolved.

FRUSTRATING to say the least. I have reached out to our Sophos Rep regarding this and updates moving forward but so far "Crickets"



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

    We had a similar issue this week (we're currently on 19 MR1 / 19 GA) - out of nothing some print-jobs stopped getting processed or being delayed for minutes (Terminalserver, printing in BranchOffice through IPSec Site2Site).
    Took way too much time troubleshooting including replacement of affected printer, etc. Remotedesktop, Mail, Ping - everything fine all time. Nothing that points to an IPsec/Firewall related problem.

    In the end disabling firewall- and ipsec-acceleration on both ends "solved" this for now.

    ...but how to get the right time to re-enable DPI, SSL, FW-Acceleration, IPSec-Acceleration... which might cause multiple branches having downtimes and problems again...

    Everytime having a problem in future, that might relate to network/firewall, would guide me to disable nearly anything on SFOS first.
    Not good for Security, not good for Downtimes, not good for Sophos reputation, not good for end-customer satisfaction...

    This is not what to expect from enterprise firewall / utm or how to handle troubleshooting.

  • 0 in reply to FFin

       
    This is mostly a me too post. We had a working configuration running 19 MR1 with 1 virtual firewall, and 3 branch office units (1 XGS2300, 2 XGS126).
    Related to a different ticket we staged SFOS 19.5.0 GA-Build197 on all three branch offices (head office was updated first without staging). On both 126's after the new firmware was staged we began seeing the firewall log its interfaces going up/down repeatedly. Enough so that it was affecting end users. The 2300 seemed to be impacted in this manner.
    Updating the 3 branch offices resolved the issue with port flapping, but users behind the 126 with a higher number of local users reported  intermittent issues with connecting to an 802.1X secured Wi-Fi all day.  (Wireless AP's are local to site, their controller is behind the 2300 and the RADIUS server is behind the head office firewall). 
    I eventually wound up turning off ipsec-acceleration in the site and wireless access improved immediately.  We didn't have as many reports regarding speed, but did get intermittent reports about delayed printing, RDP(RemoteApp) disconnects, and the inability to access WiFi were reported.
    I wound up here based on stray comment from another technician and the recommended solutions when I created a case (06003427).

    I don't see in this thread a long term answer. It seems that upgrading to a new firmware may create the situation, though each of our firewalls had been updated to 19 MR1 from a previous version. 

    I also concur that this is not terribly encouraging.

  • 0 in reply to John Nickell

    So you had an reproducible issue with V19.5 GA and the IPsec acceleration? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Yes, I believe so. I did not re-enable acceleration as a double test, but disabling it did improve the issue we were seeing specifically around our computers being able to join the 802.1X wifi.

  • 0 in reply to John Nickell

    Hi John,

    Would it be possible to share access ID of the appliance for us to take a look?

  • 0 in reply to tayfungol

    Hi  , 

    tayfungol is part of our Sophos Engineering team, and would like to take a look at your device to investigate what's causing your IPSec issues. Would you mind enabling support access and sharing the support access ID with him? 

  • 0 in reply to bobbylam

      I have remote access enabled and just emailed them to the tech assigned to ticket 06003427. Can you get them from there. I didn't think that was info I should post here for everyone.

  • 0 in reply to John Nickell

    Thanks John, I will follow up with our tech team for the access ID. Thanks again.

  • 0 in reply to tayfungol

    Please let me know if I can provide more information.

  • 0 in reply to tayfungol

     In another support case we extended the support ID's I've updated the original ticket with access IDs

  • 0 in reply to John Nickell

    ok, thanks John. We did briefly logged in earlier to two of the DT's but we haven't identified anything conclusive yet. I'll keep you posted.

  • 0 in reply to tayfungol

    We had a support session regarding the Wireless /IPSEC acceleration issue last Friday after I was able to be on site an affected location.
    We were able to reproduce one of the issues IF we enabled IPSEC acceleration and returned the MTU on our wireless devices' control plane to 1500.  In this configuration the remote site's AP were unable to connect to the controller in a remote site and therefore did not broadcast any SSID's in the remote site.  Assuming that IPSEC acceleration was already turned on prior to the updated to 19.5 (we had not turned it on or off explicitly prior to this event). 

    We seem to have come to a stable configuration with IPSEC acceleration turned on and the MTU of the wireless devices' control plane set to 1400.  

    These changes were required after the update to 19.5 and were not required while running 19 MR1.

Reply
  • 0 in reply to tayfungol

    We had a support session regarding the Wireless /IPSEC acceleration issue last Friday after I was able to be on site an affected location.
    We were able to reproduce one of the issues IF we enabled IPSEC acceleration and returned the MTU on our wireless devices' control plane to 1500.  In this configuration the remote site's AP were unable to connect to the controller in a remote site and therefore did not broadcast any SSID's in the remote site.  Assuming that IPSEC acceleration was already turned on prior to the updated to 19.5 (we had not turned it on or off explicitly prior to this event). 

    We seem to have come to a stable configuration with IPSEC acceleration turned on and the MTU of the wireless devices' control plane set to 1400.  

    These changes were required after the update to 19.5 and were not required while running 19 MR1.

Children
No Data
Unfiltered HTML