6/7/23, 6:59 PM NGFW Site-to-Site VPN Troubleshooting Guide

Welcome to the Forcepoint Customer Hub!

A place where you can easily find solutions and ask questions

Home (/S/) Search...

Help & Resource Center (/S/Knowledge-Base) Communities (/S/Group/CollaborationGroup/00B20000006kZ7aEAE) Us

Article Number

000033365

Title

NGFW Site-to-Site VPN Troubleshooting Guide

Summary

This article provides instructions how to troubleshoot issues with site-to-site VPN negotiation.

URL Name

NGFW-site-to-site-VPN-troubleshooting

Problem

This article provides troubleshooting guidance for following site-to-site VPN issues:

■ VPN negotiations fail and the tunnel does not get established

■ VPN tunnel gets established, but no connections can be opened through the tunnel

■ VPN tunnel gets established, and some connections like ping work through the tunnel, while most like Remote Desktop or file transfer
do not

Note For the VPN broker troubleshooting, see NGFW VPN Broker Operation and Troubleshooting Guide

(https://support.forcepoint.com/s/article/NGFW-VPN-Broker-Operation-and-Troubleshooting-Guide).

Resolution

Contents

■ VPN negotiation issues

■ Common IPsec negotiation error messages

■ VPN established but no connectivity through the tunnel

■ VPN established, but only some connections working

VPN negotiation issues

IPsec VPN negotiation issues happen mostly between NGFW and 3rd party tunnel negotiations due to mismatched de finitions. The main
thing to keep in mind when troubleshooting VPN negotiation issues is making sure settings match:

■ IKE version

■ IKE SA cipher algorithm

■ IKE SA message digest algorithm

■ IKE SA PFS Di ffie-Hellman group

■ IKE SA authentication method

■ IPsec SA type (ESP or AH)

■ IPsec SA cipher algorithm

■ IPsec SA message digest algorithm

■ IPsec SA compression algorithm (none or de flate)

■ IPsec SA granularity (SA per net or SA per host)

■ (Optional) IPsec SA Di ffie-Hellman group if PFS is used

■ IPsec SA site definitions (traffic selectors / proxy IDs)

If VPN negotiation fails, IPsec logs needs to be checked as first step:

1. Login to SMC with the Management Client
2. On the Home / Dashboard page right-click the firewall related to the VPN problem > Monitoring > Logs by Sender
Note If the VPN is failing between two NGFW engines managed by the same SMC, you can select both firewalls by holding
the Ctrl button down.

3. In the logs view Query panel use the drop-down menu to select VPN:

https://support.forcepoint.com/s/article/NGFW-site-to-site-VPN-troubleshooting 1/6
6/7/23, 6:59 PM NGFW Site-to-Site VPN Troubleshooting Guide

Note If you don't see the VPN option, click the Select button, scroll down, click VPN and Select.

4. Click the Apply button on the Query panel

5. (Optional) Add a filter as needed
6. Check what logs (especially the Information Message field) indicate as the reason for the VPN failure

When checking logs, keep in mind the following:

■ You should have access to logs from both gateways as IPsec standard does not permit sending exact error message to peer gateway.

■ If NGFW logs show only generic No proposal chosen without more details, check logs from peer gateway as negotiation likely failed

on that gateway side.

■ Each IPsec tunnel negotiation is composed of a initiator and a responder

■ ffic, i.e. traffic that should be sent through tunnel, while tunnel isn't yet
The initiator is the gateway which received interesting tra

established, and thus initiated the negotiation

■ The responder is the gateway which responds to negotiation request from the peer (initiator) gateway

■ Negotiation usually fails on the responder side

■ If NGFW is the initiator, and you do not have access to 3rd party peer gateway logs, try initiating new negotiation from host behind the

peer gateway so NGFW will be responder, and thus more detailed error should be seen in the NGFW IPsec logs you do have access to.

Note A mismatch in VPN settings might not trigger the same error when initiator changes. If possible, when troubleshooting IPsec

negotiation between NGFW and 3rd party gateway, try and access both gateways' logs to see both perspectives.

Common IPsec negotiation error messages

These are commonly seen IPsec negotiation errors on NGFW logs when settings do not match:

Authentication method mismatch

■ Authentication method does match between NGFW and 3rd party gateway con figuration.
■ This could be due to:

■ NGFW con figured to use pre-shared key authentication, while 3rd party gateway is configured to use certificate authentication
■ NGFW is con figured to use RSA certificate, while 3rd party gateway is configured to use ECDSA certificate.
■ Verify the same authentication method is used on both devices.

NAT-T is not allowed for this peer

■ Peer gateway requested NAT-T (NAT Traversal) to con figured to be used, but NGFW endpoint does not have NAT-T enabled.
■ Enable NAT-T on NGFW VPN endpoint settings, and install policy.

Payload malformed

■ Likely pre-shared key (PSK) mismatch, but could also be caused by NGFW receiving corrupted packets from peer gateway.

■ Validate both gateways have been con figured to use same PSK.
■ Take packet captures from NGFW and analyze with Wireshark to see if packets received are corrupted.

Peer IP address mismatch

■ The IP address of the other gateway is not speci fied as the VPN gateway end-point on this gateway.
■ Verify NGFW con figuration includes gateway with matching endpoint IP address.
■ If error is seen with a new VPN tunnel, make sure policy installation was performed to NGFW.

■ This error could happen if peer gateway is behind NAT device. In NGFW the con figuration, peer gateway endpoint is defined as actual
endpoint IP, while packets are received from the NAT IP address.

Remote ID mismatch

https://support.forcepoint.com/s/article/NGFW-site-to-site-VPN-troubleshooting 2/6
6/7/23, 6:59 PM NGFW Site-to-Site VPN Troubleshooting Guide
■ The IKE Phase 1 ID de fined for the external VPN gateway in the SMC is different from the ID with which the gateway actually identified
itself.

■ This error is usually seen when peer gateway is behind NAT, and IP address is used as IKE identity. The NAT IP address has been

de fined as endpoint IP address and IKE identity in NGFW configuration for peer gateway, but peer gateway uses the private IP of the
endpoint as IKE ID.

Timed out

■ Negotiation timed out and the peer gateway did not reply.

■ Collect traffic captures from VPN endpoint interface to see if packets are received from peer gateway.
■ If ISAKMP packets from NGFW to 3rd party gateway get dropped in the network, you'll see NGFW receiving initiator packet from peer

gateway, NGFW replying to it, but then new initiator packet is received from peer gateway.

Tra ffic selector mismatch

■ Mismatch with VPN site con figuration (3rd party gateways might call these as traffic selectors, or proxy IDs)
■ As an example on NGFW con figuration peer gateway site/traffic selector could be configured as 192.168.0.0/16, while on peer gateway it
is 192.168.0.0/20.

fi
Note When Expression and Group elements are using in the VPN site de nitions, SMC converts those to address ranges and

networks where possible as described in Use of Expression and Group Elements in VPN Site De finitions
(https://support.forcepoint.com/s/article/Use-of-Expression-and-Group-Elements-in-VPN-Site-De finitions).
 

■ Mismatch with SA granularity will cause this error as gateway con figured with SA per net granularity wants to establish IPsec SA
between each network de fined in site definitions, while gateway using SA per host granularity will want to establish separate IPsec SA
between each communicating host pair.

■ When using Route-Based VPN (RBVPN), site de finitions will be ignored, and 0.0.0.0/0 (IPv4 any network) and ::/0 (IPv6 any network) is
ffic selector during IPsec SA negotiations. This can result in Traffic selector mismatch error if peer gateway has
used as VPN site/tra

been configured with specific site definitions instead.

Note IKEv2 allows establishing IPsec SA for subset of proposed tra ffic selector. This can cause unexpected behavior when site
definitions match partially. As an example NGFW has been configured with 10.0.0.0/16 as local site definition and 192.168.1.0/24 as
remote site definition, while on peer gateway side local site is 192.168.1.0/24 and remote site for NGFW is 10.0.0.0/24. If NGFW then

initiates the negotiation, it will propose IPsec SA between 10.0.0.0/16 and 192.168.1.0/24, which peer gateway will reject as it expects

NGFW site to be 10.0.0.0/24. However if peer gateway initiates the negotiation, tunnel will get established between 10.0.0.0/24 and

192.168.1.0/24. This happens as NGFW will accept 10.0.0.0/24 as valid tra ffic selector when using IKEv2 as 10.0.0.0/24 peer gateway
fined on NGFW configuration.
proposes is part of 10.0.0.0/16 site de

For other IPsec error messages and generic IPsec log entry descriptions see IPsec VPN log messages for Forcepoint NGFW

(https://support.forcepoint.com/KBArticle?id=000019209).

VPN established but no connectivity through the tunnel

If VPN tunnel is up and you see IPsec SA established, but none of the connections through tunnel work, ask user to try opening

connections to remote servers through the tunnel, and check tra ffic logs for those connections.
■ Verify log entries show either FW_New-IPsec-VPN-Connection (Policy-Based VPN), or FW_New-Route-Based-VPN-

Connection (Route-Based VPN).

■ If logs show FW_New-Connection-Allowed, then connection was allowed but not sent to VPN tunnel. If logs suggest wrong rule is

matching, check rule tag information from the log entries.

■ If lPsec logs show Tunnel selection failed entries, this means connection matched VPN rule, but not the VPN site de finitions, resulting
in discarded connections. So verify site de finitions are correct.
■ If one of the gateways has a dynamic endpoint IP address, keep in mind gateway with dynamic IP address must always initiate the

negotiation since the peer gateway will not know which IP address it should send ISAKMP packets to. The user behind dynamic

endpoint gateway must generate tra ffic through tunnel to get negotiation initiated.
If logs show connections are allowed through the tunnel, and one of the gateways is behind NAT device, try enabling NAT-T on both

gateways. On NGFW this is done on VPN endpoint properties:

1. Login to SMC
2. Right-click firewall used in the VPN, and select Edit Single Firewall/Firewall Cluster <firewall_name>
3. In firewall element properties expand VPN section, and click Endpoints
4. Right-click endpoint element, and select Properties
5. In the endpoint properties change NAT-T selection to Enabled, and click OK to save endpoint settings.
Note When NAT-T is enabled, negotiation is started using regular ISAKMP port UDP 500. If either gateway detects NAT done

between the gateways, and both gateways have identi fied they support NAT-T, then gateway which detected NAT, will switch to
using UDP port 4500. It is also possible to force NAT-T to be used with Forced setting, but make sure peer gateway also supports

forced NAT-T where NAT-T UDP port 4500 is used from the beginning of the negotiation.

6. Click Save and Refresh button to save the firewall element, and install policy.

https://support.forcepoint.com/s/article/NGFW-site-to-site-VPN-troubleshooting 3/6
6/7/23, 6:59 PM NGFW Site-to-Site VPN Troubleshooting Guide
7. Enable NAT-T also on 3rd party gateway configuration.
8. Test if traffic works with NAT-T enabled.
If logs show connections allowed through VPN, but tra ffic still isn't working, next step is to collect traffic captures to see where
communication is cut. Since communication failure can happen on the internal side of one of the firewalls, it's best to collect packet
captures simultaneously from both VPN endpoint and internal interface of both gateways. Tips for capturing traffic:

■ If ping is allowed through the tunnel, use ping with specific payload size, e.g. 100 or 200 bytes, to generate traffic through the tunnel.
This makes it easier to link clear text ICMP echo packets to encrypted ESP packets as normally it is rare to see packets at these specific

sizes. ESP adds about 60 - 70 bytes of overhead so ESP packet carrying specific clear text packet will be 60 to 70 bytes larger than

clear text packet seen on internal interface.

■ Mapping clear text packets to encrypted ESP packets can be done as combination of timestamp, and size of both packets, and SPI of

the ESP packet.

■ To reduce size of capture files, filter the internal interface captures with source or destination host IP address, but always include ALL
ICMP and ARP messages. Example of internal interface tcpdump command:

tcpdump -s0 -ni <internal_interface_id> -w node<id>_<internal_interface_id>.pcap host <destination_host_ip_address> or icmp or arp

&

■ On external (VPN endpoint) interface peer gateway IP address can be used as filter. Example of external interface tcpdump command:
tcpdump -s0 -ni <external_interface_id> -w node<id>_<external_interface_id>.pcap host <peer_gateway_ip_address> or icmp or arp &

■ While collecting tra ffic captures from NGFW cluster, run captures simultaneously on ALL online nodes, and on BOTH internal and
external interfaces.

■ To stop tcpdump processes running in background, use below command:

killall tcpdump

VPN established, but only some connections working

In situations where VPN tunnel gets established, and ping through the tunnel is working, but Remote Desktop Session to same host

doesn't work, the first suspect is always path MTU discovery (PMTUD) issue. When user traffic is encapsulated to ESP packets, about 60 to
70 bytes of overhead is added, and if PMTUD does not work properly, this will cause situations where large packets get silently dropped

from the network. Below is example of PMTUD issue as seen when analyzing internal interface capture with Wireshark:

Above screenshot shows working TCP handshake, but TLS handshake failing due to PMTUD issue in the network. If we look at the HTTPS

server reply to Client Hello packet more closely, we can see it is acknowledgement from server telling it received the Client Hello packet:

As server sent no data (Len: 0), next packet from server should still use relative sequence number 1 (Seq: 1). But when we look at the next

packet received from server, relative sequence number is 2921:

So sequence number increased for 2920, which means 2920 bytes of data is missing. With Ethernet the default interface MTU is 1500

bytes, and IP header takes 20 bytes, and TCP header takes another 20 bytes of that leaving 1460 bytes for application data. If we multiply

1460 bytes by 2, that results in 2920 bytes, which is the amount of data missing. We can then conclude that the server sent two TCP

packets which both carried 1460 bytes of data, but those packets did not come through, and this clearly suggests there is path MTU

discovery issue in the network. For more information on PMTUD issues see Resolving Next Generation Firewall path MTU discovery issues

https://support.forcepoint.com/s/article/NGFW-site-to-site-VPN-troubleshooting 4/6
6/7/23, 6:59 PM NGFW Site-to-Site VPN Troubleshooting Guide
(https://support.forcepoint.com/KBArticle?id=How-to-resolve-Next-Generation-Firewall-path-MTU-discovery-issues).

To resolve path MTU discovery issue like this, NGFW can be con figured to rewrite MSS value in TCP SYN and SYN/ACK packets thus
forcing client and server to use a smaller packet size ensuring all resulting packets can be sent through tunnel without need to fragment

them. This is done in the Action cell de finitions on the VPN rule allowing the traffic:

In the case connectivity problem isn't caused by path MTU discovery issue, check logs to make sure connections are allowed through

VPN, and capture tra ffic to see how connections may be failing.

Another possible scenario would be mismatch with the VPN site de finitions between NGFW and 3rd party gateway, when IKEv2 is used.
This scenario is explained in more details in the VPN Tra ffic Discarded with "SA selector mismatch after decapsulation" Message
(https://support.forcepoint.com/s/article/VPN-Tra ffic-Discarded-with-SA-selector-mismatch-after-decapsulation-Message) article.

Keywords: Next Generation Firewall; site-to-site VPN; VPN problems; VPN troubleshooting; tunnel not established; IPsec VPN issue; VPN

tunnel issue; VPN connection not working; Dynamic Edge Protection; IPsec Advanced

Notes & Warnings

Dynamic Edge Protection (DEP) uses Forcepoint NGFW engines to terminate VPN tunnels from tenant devices. The error messages listed

in this article can apply also to DEP when IPsec tunnel is used.

Internal Information

CHANGELOG:

06/16/2020 thyvarinen - Added additional title to "Resolution" section and change sub-level bullet type as circle looked odd on support

portal

06/16/2020 thyvarinen - Changed few command examples to using courier new font per Jenn's email

06/17/2020 thyvarinen - Added note about IPsec errors applying to DEP.

06/17/2020 thyvarinen - Added contents links and anchors to "Resolution" section

06/18/2020 bkutsch - Reworded few sentences for readability / grammar

06/19/2020 thyvarinen - Updated note color to correct hex code #007465

12/09/2020 thyvarinen - Added link to new VPN log and error message KB 19209 and updated version list (removed old 5.x versions and

added soon to be released 6.9)

05/06/2021 thyvarinen - Fixed a sentence with incorrect term.

02/15/2022 thyvarinen - Updated keywords.

02/17/2022 thyvarinen - Made few formatting changes to improve how the article looks on the Hub.

02/18/2022 thyvarinen - Increased section titles to header 2 to make them stand out more.

03/08/2022 thyvarinen - Updated keywords.

08/11/2022 thyvarinen - Added link to the new VPN broker troubleshooting article.

10/18/2022 thyvarinen - Added instructions how to view VPN logs.

02/03/2023 thyvarinen - Added a new article link 000041491 (https://forcepoint.my.salesforce.com/articles/Knowledge/VPN-Tra ffic-

Discarded-with-SA-selector-mismatch-after-decapsulation-Message).

05/01/2023 thyvarinen - Added a new article link 000041739 (https://support.forcepoint.com/s/article/Use-of-Expression-and-Group-

Elements-in-VPN-Site-De finitions).

Internal Link

https://support.forcepoint.com/articles/Knowledge/NGFW-site-to-site-VPN-troubleshooting

(https://support.forcepoint.com/articles/Knowledge/NGFW-site-to-site-VPN-troubleshooting)

https://support.forcepoint.com/s/article/NGFW-site-to-site-VPN-troubleshooting 5/6
6/7/23, 6:59 PM NGFW Site-to-Site VPN Troubleshooting Guide

Visible To Customer

Visible To Partner

Visible In Internal App

Show In External Featured Content

Visible In Public Knowledge Base

Owning Group

DCE - Digital Customer Engagement

External Link

https://support.forcepoint.com/s/article/NGFW-site-to-site-VPN-troubleshooting (https://support.forcepoint.com/s/article/NGFW-site-to-

site-VPN-troubleshooting)

Created By

Tero Hyvarinen (/s/pro file/005370000013ziPAAQ), 5/1/2023 4:34 PM

Last Modi fied By

Tero Hyvarinen (/s/pro file/005370000013ziPAAQ), 5/1/2023 4:41 PM

Was this article helpful? 1 0

Approval History (0) (/s/relatedlist/ka2Ho000000PFx0IAG/ProcessSteps)

Files

Feedback

Contact Us (https://www.forcepoint.com/company/contact-us) Free Trials & Demos (https://www.forcepoint.com/free-trials-demos)

Careers (https://www.forcepoint.com/company/careers) Case Studies (https://www.forcepoint.com/resources/case-studies)

 (https://www.linkedin.com/company/forcepoint?trk=fc_badge)
 (https://www.facebook.com/ForcepointLLC)  (https://twitter.com/forcepointsec)
 (https://www.youtube.com/channel/UC4MbQECdktvwewRlAFwT_-w)  (http://blogs.forcepoint.com)
Legal Information (https://www.forcepoint.com/website-terms-and-conditions) Privacy Policy (https://www.forcepoint.com/privacy-policy)

© 2023 Forcepoint LLC. All Rights Reserved

https://support.forcepoint.com/s/article/NGFW-site-to-site-VPN-troubleshooting 6/6