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

    __________________________________________________________________________________________________________________

  • 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 LuCar Toni

    The psk are all the same. I've tried updating it. I believe is the responder is just confuse handling multiple initators with the same encryptions and psk. Despite having different subnets.

  • 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