Site-to-Site VPN Issues

Hey Alan Spark ,

Thank you for reaching out to the community, here it seems we are receiving from the remote end site, maybe the peer wasn't able to decrypt the message properly, or it didn't like one of the payloads (e.g. because it was configured not to use PFS and didn't expect a KE payload). Can you please share the IPsec policy being used both at the local and remote end here ?

Hi Vivek,

Thanks for your quick response. I assume by policy, you mean profile? Here are the settings of the DefaultHeadOffice and DefaultBranchOffice profiles that I am using at each end.

Head Office

Branch Office

Regards,

Alan

based on the logs -  NO_PROPOSAL_CHOSEN : looks there is a mismatch of proposals during phase 1 or phase 2 negotiation between a site-to-site VPN.

Thanks Vivek Jagad . What do you think could be the cause of the mismatch? I am sure I made the profiles exactly the same.

what about the pre-shared key, can you double check that too ?

Vivek Jagad I re-entered the preshared key at both ends and double checked that they match. No difference.

Still it shows the same error in the strongswan logs ?

Yes, still the same:

2024-04-10 13:07:40Z 09[CFG] vici initiate 'Test-1'
2024-04-10 13:07:40Z 29[IKE] <Test-1|85> initiating IKE_SA Test-1[85] to HEAD_OFFICE_IP
2024-04-10 13:07:40Z 29[ENC] <Test-1|85> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2024-04-10 13:07:40Z 29[NET] <Test-1|85> sending packet: from BRANCH_OFFICE_IP[500] to HEAD_OFFICE_IP[500] (858 bytes)
2024-04-10 13:07:40Z 02[NET] <86> received packet: from BRANCH_OFFICE_IP[500] to HEAD_OFFICE_IP[500] (858 bytes)
2024-04-10 13:07:40Z 02[ENC] <86> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
2024-04-10 13:07:40Z 02[IKE] <86> no IKE config found for HEAD_OFFICE_IP...BRANCH_OFFICE_IP, sending NO_PROPOSAL_CHOSEN
2024-04-10 13:07:40Z 02[ENC] <86> generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
2024-04-10 13:07:40Z 02[NET] <86> sending packet: from HEAD_OFFICE_IP[500] to BRANCH_OFFICE_IP[500] (36 bytes)
2024-04-10 13:07:40Z 06[NET] <Test-1|85> received packet: from HEAD_OFFICE_IP[500] to BRANCH_OFFICE_IP[500] (36 bytes)
2024-04-10 13:07:40Z 06[ENC] <Test-1|85> parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
2024-04-10 13:07:40Z 06[IKE] <Test-1|85> received NO_PROPOSAL_CHOSEN notify error
2024-04-10 13:07:40Z 06[DMN] <Test-1|85> [GARNER-LOGGING] (child_alert) ALERT: IKE SA proposals don't match. Check the phase 1 policy settings on both devices: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, 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-04-10 13:07:40Z 06[IKE] <Test-1|85> IKE_SA NO_PROPOSAL_CHOSEN set_condition COND_START_OVER
2024-04-10 13:07:40Z 06[IKE] <Test-1|85> IKE_SA has_condition COND_START_OVER retry initiate in 60 sec

Hi Alan Spark ,

Based on the logs if we refer -  IPsec troubleshooting and most common errors.

2024-04-10 13:07:40Z 06[IKE] <Test-1|85> IKE_SA NO_PROPOSAL_CHOSEN set_condition COND_START_OVER
2024-04-10 13:07:40Z 06[IKE] <Test-1|85> IKE_SA has_condition COND_START_OVER retry initiate in 60 sec

Problem #1
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.

Problem #2
In this case, the negotiation of the Authentication/Encryption algorithms and DH group is completed successfully. However, we failed to authenticate against the remote peer, and the remote peer is reporting this situation back to us.

The problem here is related to the Peer ID the remote peer expects, for example, it was configured to expect a DNS name but we are sending our IP as Peer ID.

Remote appliance logs have to be investigated to determine the exact error, but it's likely that a simple comparison between the expected Peer ID on the remote side and the configured Peer ID on our side will bring up the mismatch issue. Configure the Peer ID on the remote or on the local side in order to match.

Thanks Vivek Jagad 

I have double checked the profiles and cannot see any mismatch. I posted the screenshots above so you can review.

I have also been experimenting with site-to-site SSL VPN but could not get that working either. I created the following server profile and a corresponding client on the branch side. It indicated that the connection was success ful but I see 5 SSL authentication failure in the branch logs (initiated from the head office IP). I then get an email saying that access has been blocked for 5 minutes.

You can check finally the port status on ipfingerprints enable the UDP scan and enter the details below:

Thanks Vivek Jagad 

This is what I got for port 500 of my branch office IP:

And this is port 4500:

Note that the port forwarding settings are exactly the same in my broadband router for port 500 and 4500 so I don't understand the discrepancy between "open" and "open|filtered" but I see that the head office scan is the same.

Here is the output for the 8443 SSL VPN port:

These are the outputs for the head office IP:

Thanks Vivek Jagad 

This is what I got for port 500 of my branch office IP:

And this is port 4500:

Note that the port forwarding settings are exactly the same in my broadband router for port 500 and 4500 so I don't understand the discrepancy between "open" and "open|filtered" but I see that the head office scan is the same.

Here is the output for the 8443 SSL VPN port:

These are the outputs for the head office IP:

Interesting, when the port is marked open that is fine, but when it is marked "open|filtered"  port scanner cannot determine whether it is filtered or open. You can monitor dropped packets using command line, e.g - tcpdump -nei any port 500
to determine the traffic flow...

Please contact branch office ISP service provider to set proper port forwarding or open ports from ISP router end will fix the issue

Hi Vivek Jagad , I managed to establish the connection this morning using our secondary gateway at the head office end. As Bharat J suspected, it is likely an ISP blockage that we will need to address. However, now that I have a connection, I am unable to ping an IP in the head office from the branch network. I have followed the steps here to configure NAT (as both ends have the same IP and subnet configuration): https://docs.sophos.com/nsg/sophos-firewall/19.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/SiteToSiteVPN/HowToArticles/S2sVPNIPsecConnectionPBVPNNATSameSubnets/index.html#configure-firewall-rules_1

Any ideas?

Awesome, that's great ! You are pining with the locally NATed IP  or the original IP ?

I am pinging with the original IP.

Ping with subnets mentioned in here:

Ok, if for example the original IP address is 192.168.2.1 and the branch tries to ping that, they would ping 192.168.1.1?

I have tried the equivelent but the ping still fails. Note that our LAN IPs use subnet 255.255.192.0 but the NAT is configured with 255.255.255.0. Is this an issue?

subnet mask should be the same...

Thanks for confirming, I have changed the NAT hosts to use 255.255.192.0 and now the ping is timing out.

Monitor traffic using packet capture, see if the packets are detecting the correct rule now...