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 7078 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 Reply Children
  • 0 in reply to Vishal_R

    hi
    Most the sites that couldn't establish ipsec tunnel with our HQ are giving out the same log as No_proposal_Chosen.
    They are sophos SG125(UTM9) which would return such log. While our HQ firewall(XG450) on SFOS19 was unable to find any error log except the one established. Or perhaps because our HQ firewall is only responding.

  • 0 in reply to Vishal_R

    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)

  • 0 in reply to ywillie

    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.

  • 0 in reply to Vivek Jagad

    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.

  • 0 in reply to ywillie

    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.

  • 0 in reply to Vivek Jagad

    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.

  • 0 in reply to ywillie

    I have to say these ipsec tunnels are no longer feasible with sophos constantly pounding in new firmwares that plague it with more issues. My only last effort is to ditch firewall entirely and look into ztna solution. 

  • 0 in reply to ywillie

    If you are able to use dyndns names, you could use those instead of * as peer. Dyndns doesn't have to break the bank and it seems it will get you rid of all your current trouble.

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • 0 in reply to ywillie

     , I assume you are using IKEv1 ( based on one of the logs you posted, where we see the log as "parsed ID_PROT request" ). And I assume you are using Policy Based IPsec VPN.

    We have introduced a feature in v20.0.GA where we could use unique PSK across IPsec tunnels - this is only applicable for IKEv2 type of tunnels as IKEv1 does not make use of ID field.  You are advised to use IKEv2 for the IPsec tunnels to make use of * notation on Responder's remote gw filed alongwith local ID and/or Remote ID. 

    If you are still facing issues, pls DM me (sreenivasulu.naidu@sophos.com) to go over a zoom call to understand your setup and issue further.

  • 0 in reply to Sreenivasulu Naidu

    Hi

    Yes . It's policy based and IKEV1 i'm having trouble with. Our branches are UTM and it only have IKEV1 even though our HQ firewall is using XG.

    Perhaps there's a post somewhere to highlight what ikev1 and ikev2 supports. Such as ikev1 do not support ID field.
    Because to me, i've exhausted almost every options i can come up with.

    Actually , previously we do not have firewall rules created for each tunnel. We have roughly 30 tunnels and after i'm requested to provide logs to monitor each tunnel, i saw the convenience of ticking creating firewall rule option on each tunnel.
    We now have 30 rules for each tunnel and seems to me everything runs fine at first. Only recent after restarting our HQ firewall, certain tunnel refuse to go back up.

    According to my vendor, XG450 is consider an old hardware. The newer firmwares are not well suited for XG450 that are soon to be EOL. Subsequently creating so much of policy to monitor those tunnel, it'll cause the tunnel to go haywire since they're multiple * .
    The only way is to upgrade to XGS firewall .

    Assumingly if their judgement is correct, we still have till 2025 before our license expire. Which means we still need to hang onto this firewall for a year which is pretty long.

Unfiltered HTML