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 6692 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

    Hi  Thank you for reaching out to the Sophos community team, Without reviewing the logs it would be bit difficult to confirm why 3-4 sites tunnels not coming up with firewall reboot, reviewing the logs will help to conclude the issue and to confirm solution in a better way.

    Sophos Firewall: Troubleshooting site to site IPsec VPN issues
    community.sophos.com/.../sophos-firewall-troubleshooting-site-to-site-ipsec-vpn-issues

    However if you suspect an issue is due to 1 same PSK being used and due to that reason you are thinking to switch those few problematic tunnels from PSK to RSA method then from SF OS V20, there are IPsec Enhancements that support unique PSK support for the same local and remote gateway connections.

    For more info release note of V20 - community.sophos.com/.../sophos-firewall-v20-is-now-available

    Regards,

    Vishal Ranpariya
    Technical Account Manager | Sophos Technical Support
    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'Verify Answer' link.

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

Reply
  • 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)

Children
  • 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, Global Support & Services 

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case


    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, Global Support & Services 

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case


    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.

  • 0 in reply to Sreenivasulu Naidu

    May i know if there's a way to do a packet inspection like on wireshark to check what kind of information is both side (Initiator and Responder) trying to send to each other ?

  • 0 in reply to ywillie

    If you are sure that both IPsec peers has same/matching Phase1 and Phase2 policy, it is unlikely that no proposal chosen error is pointing to mismatched proposals; some of the errors seen with IKEv1 are not quite intuitive;  tcpdump of ike negotiation packets gives encrypted packets, a relatively lengthy procedure to be used to decrypt the packets in wireshark (as below):

    On SFOS, from the Advanced shell cli, enter below to increase the log level of charon process

     SF01V_SO01_SFOS 17.5.15 MR-15# ipsec stroke loglevel ike 4

    - Establish the IPSec tunnel

    SF01V_SO01_SFOS # tcpdump -vvni Port1 port 500 or port 4500 -w /usr/share/userportal/tcpdump.pcap

    If the above path is readable, do this from the cli 'mount -no remount,rw /'

    ipsec stausall   //get the ikev1 spi id ex: 59188f30249888da_i        // here 'i' is Initiator

    In /log/charon.log look for 32 bytes, this is the Encryption key

    encryption key Ka => 32 bytes @ 0x7f76140135e0

     0: 82 09 85 BA B7 FE 11 AC F3 E4 BB 17 51 C2 68 7A

    16: 88 3F 18 A5 00 62 64 18 CB 8E B6 79 20 62 E8 45

    Open tcpdump.pcap file in wireshark; Go to Preferences → Protocols; search for ISAKMP; enter UDP port, it could be port 500 (no NAT scenario) or 4500 (NAT'ed scenario) as the case may be.

    Click on 'IKEv1 Decryption Table' Edit button, hit on + sign and enter Cookie and Encryption Key noted earlier.

    Now wireshark shows decrypted packets.

Unfiltered HTML