Advisory: Support Portal Maintenance. Login is currently unavailable, more info available here.
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?
One do not even need to create a new "normal" IPSec connection, just open and save existing ones. This causes immediate damage to the preshared key on the Sophos Connect server. Very frustrating...
Let me understand. You are saying a Sophos Connect Client policy using PSK is defined. Now you define a new IPsec connection (is this defined for S-2-S or Remote Access?) using PSK. At this point you are saying that PSK in Sophos Connect Client policy is also getting changed. That is one problem you are defining. At this point if you export the Sophos Connect Client policy and import it in Sophos Connect Client it will give an error?
Please clarify so I can reproduce the problem and let you know tomorrow
I have an original tgb file with an encrypted PSK key generated in February. I can also upload to the router a copy of the configuration from two days ago, with which this tbg file works properly.
Unfortunately, this is not the only problem. Regardless of the password change, the encryption protocol has also been changed. Hence the second message about which I wrote "Received NO_PROPOSAL_CHOSEN notification from gateway".
Summarizing:Editing a normal IPSec connection resulted in an unexpected change in the PSK key and encryption protocols in Sophos Connect. As a result, I am unable to set up vpn even using a freshly exported configuration. And at any time I can demonstrate it live.
The tgb file never encrypts the PSK.
You're right, and what I was taking for the encrypted PSK key was in fact the key that the system automatically generated during the first configuration of Sophos Connect.
My problem resulted from limitations of the encryption system used in XG Firewall. For all IPSec connections that have a common source and destination, one and the same PSK is used - and its change affects all such connections. In my case, I edited IPSec connections intended for mobile users who do not have a fixed IP address. All these connections had "*" in the "remote gateway" field. Unfortunately, Sophos Connect also uses such addressing scheme, which is why the change of the PSK key in those IPSec connections also affected the PSK key entered into Sophos Connect.
However, doing cut corners is quite risky and may end with an unexpected overwriting of valid PSK key on either side. The Sophos Connect interface gives the impression that it is a functionally completely separate application, unrelated to the interface in which IPSec connections are configured, and it is difficult to guess that PSK keys are common. It would be good to improve it in the next versions of the firmware.
Thank you very much for your help and for today's Zoom session.
My problem with the NO_PROPOSAL_CHOSEN error has also been solved, thank you again for your help. It turned out that after changing the PSK key also changed the encryption method used by the Sophos Connect server. What's more, the newly generated configuration file for the client contained incorrect settings, which resulted in an error as above when attempting to set up the connection.
Solution to this problem - according to received instructions - is given below:
If you are using scx file then edit the file and change the proposals line "proposals": "aes256-sha2_256-modp4096", to: "proposals": "aes256-sha2_256-ecp256"
If you are using the tgb file then replace all instance of GRP2 with GRP19. There are six lines that will be changed.
Sophos Connect 1.3 is released and it is now available via your firewall via pattern update. You can go to System->Backup & Firmware->Pattern Updates and click Pattern update now to downloaded in case it is not there already.
Please do let us know how this new version works for you after a week of usage. Looking for feedback from customers for this new release.
The problem seems to be different here.I just opened a ticket.
SFOS: 17.5.8 MR-8
If you create ipsec connections in the XG and assign a Pre Shared Key, the keys will also be replaced in already existing ipsec connections.the same happens with the Pre Shared Key of the Sophos Connect Client!This means that all existing Pre Shared Keys and all connections are always replaced by the last Pre Shared Key created.
AEX said: all existing Pre Shared Keys and all connections are always replaced by the last Pre Shared Key created.
I think the XG has been like this for quite some time.
Sophos XG 450 (SFOS 18.0.3 MR-3)
Sophos R.E.D 50 x 2
Always configuring new stuff.....
Keyur can you track this case?
I would say, it should not happen at all.. I have couple of SC configurations running with IPsec S2S and there are no interrupts at all.
LuCar Toni said:I would say, it should not happen at all.
I agree - but it sure does.
Create two IPSEC tunnels and see - set the PSK for the first and change it for the second and the first will be set to the same as the second.
Crazy hey.... :-)
Those tunnels, respond only or initiate connection?
Both tunnels build via IPsec tab or one ipsec and one with Sophos connect tab?
As far as i know, XG is not capable of using PSK probing.
XG is not capable of using PSK probing. Unless I am doing something wrong. I have also seen the same problem.
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...
Hi Detlef Halbritter
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.
KingChrisCommunity Support | Sophos Support Sophos Support Videos | Knowledge Base | @SophosSupport | Sign up for SMS Alerts | If a post solves your question use the 'This helped me' link
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.