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

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.

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.
  • So far i tried the rsa method and i got this error. Same.. Tunnel would refuse to go up.

    2024-01-03 02:29:04Z 25[NET] <555944> received packet: from 65.39.20.15[500] to 103.126.16.11[500] (256 bytes)
    2024-01-03 02:29:04Z 25[ENC] <555944> parsed ID_PROT request 0 [ SA V V V V V V V V V ]
    2024-01-03 02:29:04Z 25[IKE] <555944> received strongSwan vendor ID
    2024-01-03 02:29:04Z 25[IKE] <555944> received Cisco Unity vendor ID
    2024-01-03 02:29:04Z 25[IKE] <555944> received XAuth vendor ID
    2024-01-03 02:29:04Z 25[IKE] <555944> received DPD vendor ID
    2024-01-03 02:29:04Z 25[IKE] <555944> received NAT-T (RFC 3947) vendor ID
    2024-01-03 02:29:04Z 25[IKE] <555944> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
    2024-01-03 02:29:04Z 25[IKE] <555944> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
    2024-01-03 02:29:04Z 25[IKE] <555944> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
    2024-01-03 02:29:04Z 25[IKE] <555944> received draft-ietf-ipsec-nat-t-ike-00 vendor ID
    2024-01-03 02:29:04Z 25[IKE] <555944> 60.49.40.10 is initiating a Main Mode IKE_SA
    2024-01-03 02:29:04Z 25[CFG] <555944> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536
    2024-01-03 02:29:04Z 25[CFG] <555944> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_3072, IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_8192/MODP_2048, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_8192/MODP_2048
    2024-01-03 02:29:04Z 25[IKE] <555944> no proposal found
    2024-01-03 02:29:04Z 25[ENC] <555944> generating INFORMATIONAL_V1 request 3319343756 [ N(NO_PROP) ]
    2024-01-03 02:29:04Z 25[NET] <555944> sending packet: from 103.126.16.11[500] to 65.39.20.15[500] (56 bytes)

  • 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.

  • The problem appears to be a mismatch between Phase 1 acceptable proposals between the two peers.

    Encryption, Authentication, and DH group must match in order for the VPN to come up, peer IP must also match.

    You have to investigate the configuration on both peers and make sure they match the settings. If they match the settings, the remote peer administrator has to investigate the problem on his side, since the remote firewall is refusing the connection.

    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Technical Support, Global Customer Experience

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case  | Security Advisories 
    Compare Sophos next-gen Firewall | Fortune Favors the prepared
    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • 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. 

    __________________________________________________________________________________________________________________

  • hi. All authentication, encryption and DH group are matching over both side.
    The issue lies with initiator is on a dynamic wan ip.
    Responder is only responding to * 
    Initiator is sending the request over to responder but somehow responder is confuse and does not know which responder to look at since i have dozens of intiators using dynamic ip.
    This problem doesn't exist back in v17 and v18. It becomes a nightmare after v18.
    I'm getting really frustrating over this.

  • may we know the current active firmware on the appliance ?

    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Technical Support, Global Customer Experience

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case  | Security Advisories 
    Compare Sophos next-gen Firewall | Fortune Favors the prepared
    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • 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.

  • It's version SFOS 19.5.3 MR-3-Build652 . I'm really frustrated and upset over how sophos rolls out their latest firmware without considering the bugs that are in place. Each firmware put us more in trouble then with ease to setup.
    We reach out to support, it routes us back to our vendor. And the irony thing about some vendors are not even properly trained to respond to such bugs. Because sophos wasn't even constantly engaging their vendors to ensure that they are equiped with the latest knowledge and known bugs solution to support customers.
    Sophos is doing is simply one dimensional. Call that a cybersecurity solution experts. That's seriously rubbish.