Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 31 replies
  • Answers 4 answers
  • Subscribers 43 subscribers
  • Views 7099 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

Multiple IPSEC Tunnels with Combination of RSA and Preshared Keys.

ywillie

Been using 1 same preshared keys for over 10 sites that backhaul back to our HQ till now.
However eversince v18 onwards, it's getting more and more unstable. After restarting our HQ Firewall, at least 3-4 sites tunnels wouldn't up.
Ticked the create firewall policy rule for each ipsec to enable me to monitor each tunnel separately.
Seems it creates more unstability then doing anything good.

I'm thinking of switching like 4 sites that couldn't up automatically to rsa while some still retain preshared keys.
I wonder will it cause unstability across all 10 sites ?



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

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

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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.

  • 0 in reply to LuCar Toni

    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.

  • 0 in reply to ywillie

    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. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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.

  • 0 in reply to ywillie

    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. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    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.

  • 0 in reply to ywillie

    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. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    just a question, if identifier works . wouldn't it be able to solve the issue back in v19 with only 1 psk ?
    Since every tunnel will have it's own unique identifier so that even it responds to multiple initiators that are *.
    If it doesn't, how would it solve the issue that v19 wasn't able to.

  • 0 in reply to ywillie

    If all tunnels use the same PSK, it should work in V19.0.

    So if you change all UTMs to the same PSK, it will work. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    They are all on same PSK like i mentioned earlier. v19 is already not working. i don't see v20 going to solve the issue.

  • 0 in reply to ywillie

    Try to update the PSK on both peers everywhere again. Likely it is not correct. Because this is likely the problem here. Or do you use Ipsec Remote access as well? This will also override the PSK. 

    __________________________________________________________________________________________________________________

Reply
  • 0 in reply to ywillie

    Try to update the PSK on both peers everywhere again. Likely it is not correct. Because this is likely the problem here. Or do you use Ipsec Remote access as well? This will also override the PSK. 

    __________________________________________________________________________________________________________________

Children
Unfiltered HTML