Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Exonix
Advisor
Jump to solution

Telnet works, but application doesn't

Hello everyone,

we have one Security Gateway R80.40 with S2S VPN configured as shown on the picture:

net1.png

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!

 

0 Kudos
1 Solution

Accepted Solutions
Exonix
Advisor

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.

View solution in original post

0 Kudos
3 Replies
Chris_Atkinson
Employee Employee
Employee

Are the left side servers running the same OS?

Could potentially be an MTU issue requiring MSS clamping.

CCSM R77/R80/ELITE
0 Kudos
Exonix
Advisor

they have the same OS Windows Server and same MTU

0 Kudos
Exonix
Advisor

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events