Multiple IPSEC Tunnels with Combination of RSA and Preshared Keys.

You can move to V20.0 and use different PSKs per Tunnel while using Identifier. 

Hi.. many of our sites are using utm9(Branches) that are using initiating and our HQ(SFOS19) as respond with * since major of the sites are dynamic wanip. 
I've checked ipsec best practices by sophos.
Seems to suggest using rsa and configuring with ip type as dns to prevent config identity confusion with all these sites.

Hi.. many of our sites are using utm9(Branches) that are using initiating and our HQ(SFOS19) as respond with * since major of the sites are dynamic wanip. 
I've checked ipsec best practices by sophos.
Seems to suggest using rsa and configuring with ip type as dns to prevent config identity confusion with all these sites.

By moving and using V20.0 GA, you can use the Identifier + Wildcard to separate the IPsec Tunnels + PSK. 

This will resolve your problem. 

Do you have a snapshot of how these identifier+wildcard look ? I have tones of tunnels, once i perform a firmware update, even reverting back the firmware might possibly trigger some of our ipsec tunnels unable to come back up.

You could do the change now, it will not affect the tunnels and then update. 

You are using those two values in IPsec: 

This will define what peer we are expecting and what we introduce ourself.

On utm you do the same: 

You can define there whatever you want, as long as it matches: 

SFOS: DNS sfos // Remote: DNS utm1

UTM1: DNS: utm1  // Remote: DNS sfos 

Just suggestions. But this will give the wildcard tunnel the option to separate the tunnels. 

By the way: What happens is quite easy: https://community.sophos.com/sophos-xg-firewall/f/discussions/136338/ipsec-strongswan-issue/505265#505265 

thanks. i'll try to do it. I saw this suggestion from sophos ipsec best practices. Although it includes rsa which is why i thought of going slowly migrating to rsa and ditch preshared keys eventually.

You can do both. SFOSv20.0 offers the option via PSK. 

In the End, i am the fan of RSA Keys anyway but it is also a good choice to work with Identifier in IPsec anyway. 

On SFOS i was able to do that selection but on UTM , there's no option to select DNS.
What i ended up doing is selecting hostname as an option instead. By default, it's on IPV4 address. if i tried to input anything other than ipv4, it would get the error msg.


I tried using email and hostname. nothing works. Tunnel just wouldn't go up.

So: Did you upgrade to V20.0 on SFOS? 

Otherwise this will not work. 

The identifier can be anything. Take Email Address and give each UTM something like "UTM1@domain.com" etc. Just to differentiate it later. Or give them Location names. 

What you need to do next (one time) is to setup the PSK one more time so SFOS can save it. 

I have yet to upgrade to V20. Given that i actually had 30 tunnels to be precise. Any issue , i won't be able to up those tunnels.
However, our private cloud has a managed fortigate that backhauls all of our branches . Fortigate ipsec seems to work so flawlessly without ipsec trouble. And how frustrating to know that sophos xg and utm9 couldn't even work properly despite being the same product.

So let me rephrase what happens: 
If you use a Wildcard on SFOS, SFOS can only have 1 PSK for all Wildcard Tunnels in V19.5 and below. 
But what you can do: You can override the tunnel all the time. 
Meaning: 

Tunnel 1 
Tunnel 2

You have PSK1 for Tunnel 1 and PSK2 for Tunnel2. 

If you select PSK1 for Tunnel1, it will build up the tunnel fine. PSK is only used for Phase 1 IPsec. Then in Phase 2 no PSK is needed and the tunnel is stable. What you are doing: You set PSK2 for Tunnel2 and bring Tunnel2 up. But SFOS will override PSK2 to Tunnel1. Which does not affect the active tunnel but on a reboot the tunnel1 will not come up, as the PSK2 is expected for all tunnels but UTM1 in Tunnel1 used PSK1.

In V20.0 you can use the identifier to tell SFOS which UTM needs which PSK. to do that, you setup the identifier and select the PSK one more time and the tunnels should come up.