Scope: IPv4 site-to-site IPsec on centrally managed Check Point Quantum Security Gateways running Gaia R82. The main example uses domain-based VPN. A separate check covers route-based VPN with a VPN tunnel interface (VTI). Addresses are illustrative.
A tunnel can have an active IPsec security association (SA) while a specific application still times out. Start with one connection and trace it across both gateways. This helps separate a VPN domain mismatch from an Access Control drop, unexpected NAT, or a missing return path.
Symptom and test flow
The Site A client 10.10.10.25 cannot reach the Site B server 10.20.20.50 on TCP/443. The remote VPN peer is 198.51.100.20 in this example. Make a fresh connection from the LAN client, note the timestamp, and use the same source, destination, and port for every check.
1. Confirm the tunnel and compare VPN domains
vpn tu tlist -p 198.51.100.20Run this read-only check on the gateway handling the test traffic. Use the corresponding peer address on the other gateway. In a cluster, first identify which member is processing the flow. Look for the expected peer and relevant tunnel entries. If multiple tunnels exist for that peer, confirm the entry you are inspecting corresponds to the affected network pair.
In SmartConsole, check the local and peer VPN domains, including any VPN domain defined for this specific community. Confirm that both hosts belong to the intended domains and compare the negotiated traffic selectors with the peer’s settings. The local and remote networks are reversed at the other end. For an interoperable peer, also compare the peer’s proxy IDs or Phase 2 selectors.
2. Check Access Control, anti-spoofing, and NAT
In SmartConsole Logs & Monitor, filter by the source, destination, and test time. Check the gateway that logged the event, the rule, the action, and any available translation or VPN details. Verify the installed Access Control rule allows the flow and that its VPN column matches the intended community or direction where enforced. If the log shows an anti-spoofing drop, verify the interface topology and the networks expected on that interface. An empty log is inconclusive if the relevant rule does not track the connection.
If the design preserves original addresses, check the applied NAT policy and whether the community is configured to disable NAT inside the tunnel. If the design intentionally translates traffic, compare the translated addresses with the peer’s selectors, route, and policy. Avoid changing the community-wide NAT setting before checking which other flows it affects.
3. Verify the forwarding path and return route
For domain-based VPN, the VPN domains determine whether the flow belongs to the VPN. Check that the client traffic reaches the correct gateway, the remote peer is reachable, and the far gateway and server have a return path. Do not expect to find a VTI route in a domain-based deployment.
For route-based VPN, verify the route to the remote network points to the intended VTI and that the peer has a return route. If both VPN methods are configured, check for a competing domain-based match. Check Point documents that domain-based VPN takes precedence by default in this case. Where directional VPN matching is configured, verify that the installed rule covers the traffic direction you are testing.
4. Compare tunnel counters and capture the connection
If tunnel volume statistics are already enabled, compare encrypted and decrypted byte counts before and after a few test connections. Counts may include other sessions. A rise on Site A should be checked against corresponding activity on Site B. If the counters are unavailable or noisy, correlate the logs with a short filtered capture.
fw monitor -F "10.10.10.25,0,10.20.20.50,443,6" -F "10.20.20.50,443,10.10.10.25,0,6" -ci 20 -co 20Run the capture in Expert mode for a short test window and stop it with Ctrl+C if the packet limits are not reached. Each filter covers one direction. 0 in the client port position allows any ephemeral port and 6 selects TCP. If NAT is expected, account for translated tuples when choosing filters. Treat capture output as sensitive.
No SYN reaches Site A: check the client gateway, VLAN, or upstream route. Site A sees a SYN but Site B does not: compare the selected VPN domain or VTI, policy, NAT, and SA evidence. Site B forwards the SYN but sees no SYN-ACK: check the server listener, host firewall, and default gateway. Site B sees a reply but Site A does not: trace the return path and compare encryption and decryption on the two peers.
5. Verify the fix
Repeat the same TCP/443 test from the original LAN client. Confirm the TCP handshake and an application response. Verify that the expected gateways handled both directions and document the rule, route, NAT, or selector that explained the failure. The initial checks above do not require deleting SAs or restarting the tunnel.
References and related guides
Check Point R82 tunnel list command · FW Monitor · VPN tunnel interfaces · R82 Site to Site VPN Administration Guide
Using a different firewall on the other side? See the FortiGate IPsec troubleshooting guide and the Palo Alto IPsec troubleshooting guide.