- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hello everyone,
we have one Security Gateway R80.40 with S2S VPN configured as shown on the picture:
we initiate a connection in a browser for the server 192.168.108.21 (left side) to the server 192.168.105.55 (right side) - it works.
then we initiate a connection in a browser for the server 192.168.108.22 (left side) to the server 192.168.105.55 (right side) - it doesn't work. TCPDUMP shows TCP Retramsmittion - the server 192.168.105.55 constantly answers to the source server, but the answer does't reach destination. It looks like the traffic was not sent to the S2S Tunnel:
14:30:56.463307 IP 192.168.108.22.50366 > 192.168.105.55.8080: Flags [SEW], seq 3783873076, win 64240, options [mss 1383,nop,wscale 8,nop,nop,sackOK], length 0
14:30:56.463311 ethertype IPv4, IP 192.168.108.22.50366 > 192.168.105.55.8080: Flags [SEW], seq 3783873076, win 64240, options [mss 1383,nop,wscale 8,nop,nop,sackOK], length 0
14:30:56.463689 ethertype IPv4, IP 192.168.105.55.8080 > 192.168.108.22.50366: Flags [S.], seq 2614875695, ack 3783873077, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:30:56.463689 IP 192.168.105.55.8080 > 192.168.108.22.50366: Flags [S.], seq 2614875695, ack 3783873077, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:30:57.486629 ethertype IPv4, IP 192.168.105.55.8080 > 192.168.108.22.50366: Flags [S.], seq 2614875695, ack 3783873077, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:30:57.486629 IP 192.168.105.55.8080 > 192.168.108.22.50366: Flags [S.], seq 2614875695, ack 3783873077, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:30:59.502473 ethertype IPv4, IP 192.168.105.55.8080 > 192.168.108.22.50366: Flags [S.], seq 2614875695, ack 3783873077, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:30:59.502473 IP 192.168.105.55.8080 > 192.168.108.22.50366: Flags [S.], seq 2614875695, ack 3783873077, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:31:03.726476 ethertype IPv4, IP 192.168.105.55.8080 > 192.168.108.22.50366: Flags [S.], seq 2614875695, ack 3783873077, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:31:03.726476 IP 192.168.105.55.8080 > 192.168.108.22.50366: Flags [S.], seq 2614875695, ack 3783873077, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:31:11.922558 ethertype IPv4, IP 192.168.105.55.8080 > 192.168.108.22.50366: Flags [S.], seq 2614875695, ack 3783873077, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:31:11.922558 IP 192.168.105.55.8080 > 192.168.108.22.50366: Flags [S.], seq 2614875695, ack 3783873077, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
And now most intresting thing: when we initiate a connection in the PowerShell using Telnet or TNC command, or ping - it works:
14:33:42.038794 IP 192.168.108.22 > 192.168.105.55: ICMP echo request, id 1, seq 234, length 72
14:33:42.038799 ethertype IPv4, IP 192.168.108.22 > 192.168.105.55: ICMP echo request, id 1, seq 234, length 72
14:33:42.039054 ethertype IPv4, IP 192.168.105.55 > 192.168.108.22: ICMP echo reply, id 1, seq 234, length 72
14:33:42.039054 IP 192.168.105.55 > 192.168.108.22: ICMP echo reply, id 1, seq 234, length 72
14:33:42.071356 IP 192.168.108.22 > 192.168.105.55: ICMP echo request, id 1, seq 235, length 72
14:33:42.071364 ethertype IPv4, IP 192.168.108.22 > 192.168.105.55: ICMP echo request, id 1, seq 235, length 72
14:33:42.071781 ethertype IPv4, IP 192.168.105.55 > 192.168.108.22: ICMP echo reply, id 1, seq 235, length 72
14:33:42.071781 IP 192.168.105.55 > 192.168.108.22: ICMP echo reply, id 1, seq 235, length 72
Before I open Support Case, maybe someone on the forum can help me in this question: Why connection works from one server, but from another it doesn't even if the Ports are open?
Thank you in advance!
the problem was on the remote side: the server was sending data to the default router, which forwared (routed) to another router on the same network. As soon as the remote side configured a static route (avoiding the default route) for the target network on the server, the problem disappeared.
Are the left side servers running the same OS?
Could potentially be an MTU issue requiring MSS clamping.
they have the same OS Windows Server and same MTU
the problem was on the remote side: the server was sending data to the default router, which forwared (routed) to another router on the same network. As soon as the remote side configured a static route (avoiding the default route) for the target network on the server, the problem disappeared.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 19 | |
| 17 | |
| 13 | |
| 8 | |
| 7 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 |
Tue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY