17.5.3 MR3 - creating an IPSec connection damages the configuration of the Sophos Connect server

I have a very serious problem with router running under 17.5.3 MR3 firmware. Previously we have configured dozens of IPSec site-to-site connections with preshared key. All of them were created in previous versions of the firmware and after migration to 17.5 worked without any problems.

Unfortunately now, at the moment when I add a new IPSec connection with preshared key, the configuration of the Sophos Connect server is dispersed. An attempt to establish a VPN connection with it ends with an "Incorrect pre-shared key" error. As I've checked, this effect only occurs using preshared keys, the same connection created using RSA keys does not cause errors.
That preshared key itself is 10 characters long and does not contain any special characters

It does not help generate a new configuration file in Sophos Connect and upload it to the client, nor try to change the preshared key to another one on the router. The only solution is to restore the router configuration from backup.

What can I do with this? Is this a known bug in this firmware version? Will help me return to the earlier version of the firmware?

  • In reply to LuCar Toni:

    XG is not capable of using PSK probing. Unless I am doing something wrong. I have also seen the same problem.

     

    Ramesh

  • In reply to rmk_2018:

    We have the same problem. Is there an update from Sophos possible?

    How could I solve this Problem? Is it not possible to work with certificates...

     

  • In reply to Detlef Halbritter:

    Hi  

    The XG does not support preshared key probing.  What this means is that if you have 2 IPsec tunnels, which would include Sophos Connect Client and L2TP, with the same local and remote endpoints, generally remote endpoints being "*" or "any", any PSK change is applied to all of them.

    This is the way the XG has been for some time.  To overcome this, your only option is to decide on which IPsec technology you want to use, and stick with that for your end users.  You could also transition to SSL VPN which is not affected. 

    For site-to-site connections, do not use "*" as the remote endpoint.  Use an actual IP address or FQDN.  You can utilize a dynamic DNS for the remote side which will then be a solution to.  However its always recommended to use static IPs where possible for site-to-site deployments.

    In the interests of not continuing on old threads, if you have a problem I would suggest you create your own post.

    Thanks!

  • In reply to KingChris:

    As far as i know, PSK Probing is no real standard. It is most likely a implemented technique to workaround the need of knowing the peer PSK.

    But this comes with some downsides. In bigger setups, there could be actually issues in this implementation. 

    I would recommend to either start with Peer DDNS Records (PS: Sophos XG Offers a free DynDNS Service) or use a Identifier in the Tunnel. Should be enough to give XG a possibility to identify the coming connection. Something like the Remote ID Type.

     

    This will give XG the option to identify the Peer and use the proper Key. A better option then a PSK Probing.