Multiple IPSEC Tunnels with Combination of RSA and Preshared Keys.

Hi ywillie 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

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)

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.

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 ?

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.

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. 

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.

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.

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.

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 ?

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.

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.