An external client connects to a published HTTPS address, but the browser times out. On a Check Point Quantum gateway, the fastest way to isolate the fault is to follow the same connection from the external interface to the translated server and back.
This walkthrough uses Gaia R81.20, a single IPv4 gateway, and manual destination NAT. The example publishes 203.0.113.10:443 as 10.20.30.40:443. The external test client is 198.51.100.25. Replace the documentation addresses and interface names with values from a network you administer.
1. Check the rule installed on the gateway
In SmartConsole, open the intended policy package and its NAT rulebase. For this example, the original destination is the public address, the original service is HTTPS, and the translated destination is the internal server. Source and service remain Original. Confirm the rule’s Install On target and inspect preceding rules that could match the same connection.
In Logs & Monitor, locate the latest test by timestamp, original source, and public destination. Open the details and compare the Access Control rule, action, origin gateway, and any translation fields shown. If no log appears, confirm logging is enabled for the relevant rule and use an interface capture to see whether the SYN arrived.
On the gateway, verify the installed policy name and timestamp:
cpstat -f policy fwA published SmartConsole change still needs to be installed on the intended gateway before it can affect the test.
Check Point R81.20 – Manual NAT rules · Check Point R81.20 – CLI Reference
2. Prove the public address reaches the gateway
In Gaia Expert mode, use a narrow capture on the external interface. Generate one fresh connection from the test client while the capture runs. Press Ctrl+C once you have enough evidence or the test ends.
tcpdump -ni eth0 -c 20 'host 198.51.100.25 and host 203.0.113.10 and tcp port 443'If the SYN never arrives, check the upstream router. When the public address is on-link and the router ARPs for it, verify that it resolves to the expected gateway MAC. Check Point documents automatic Proxy ARP behavior for automatic NAT and manual Proxy ARP configuration for manual NAT. If the public prefix is routed to the gateway’s interface address, verify that route and next hop first. In that design, the upstream router normally resolves the next-hop address.
Check Point R81.20 – Automatic and Proxy ARP
3. Confirm the translated packet and the server reply
Run a second narrow capture on the interface toward the server while repeating the test. The filter assumes destination-only NAT, so the server still sees the original client address.
tcpdump -ni eth1 -c 20 'host 198.51.100.25 and host 10.20.30.40 and tcp port 443'
ip route get 10.20.30.40Use the route lookup to verify the gateway’s route toward the server. If you need firewall inspection-point evidence, Check Point’s FW Monitor supports multiple five-tuple filters. Match both the public and translated tuples in both directions when correlating NAT. For this example, use a brief capture and stop it with Ctrl+C:
fw monitor -F "198.51.100.25,0,203.0.113.10,443,6" -F "198.51.100.25,0,10.20.30.40,443,6" -F "203.0.113.10,443,198.51.100.25,0,6" -F "10.20.30.40,443,198.51.100.25,0,6"Here, zero in a port field matches any port and protocol 6 is TCP. Adapt the filter if the rule also translates the source or service.
| Observation | Next check |
|---|---|
| SYN missing on the external interface | Verify public DNS, upstream route or ARP, and the actual ingress interface. |
| External SYN arrives, translated SYN is absent | Review Access Control, NAT match and installation target, and routing to the server. |
| Translated SYN arrives at the server, SYN-ACK is absent | Check the listening service, host firewall, and local application health. |
| Server sends SYN-ACK, gateway never sees it | Check the server or downstream router’s return route to the external client. |
| TCP completes, HTTPS still fails | Correlate TLS or HTTP errors with the server or reverse proxy logs. |
Check Point R81.20 – FW Monitor
Worked example: The translated SYN arrives, but the reply takes a different gateway
The external capture shows repeated SYNs for the public IP. The internal capture shows the translated SYN going toward the server. A server-side capture confirms the application replies, but its default gateway forwards the reply through another router. Correct the return path through the approved routing change, then repeat the HTTPS test. Verify the SYN-ACK on both sides of the Check Point gateway and confirm that the external client receives the expected application response from the published address.