0

Currently when connecting to our work server through VPN and RDP the RDP connection drops every once in a while and then comes back. I started a continuous ping to the server and noticed that it drops when then TTL changes from 127 to 63.

We are using Fortinet VPN.

What could be causing this and how can I solve this?

I tried using a different RDP client. I also tried to RDP with the IP address instead of the server name.

Screenshot of ping

2 Answers 2

1

The returning ICMP Echo Reply TTL shows the pinged node's initial TTL minus the path decrements.

When the TTL jumps like that it indicates different paths or even different end nodes. 64 as initial TTL often indicates a *nix system (Linux, xBSD) while 128 indicates Windows. However, a path decrement of just 1 shows that you're pinging through the tunnel. Instead, you should try pinging along the tunnel, using the VPN terminator's public address. Using continuous tracert or pathping could also help analyzing the situation, as well as logs from or perhaps specific packet capturing on the VPN endpoints.

In conjunction with the also jumping reply delay, I'd guess there are different paths from the pinged node back to you. Since you're asking about VPN it's also possible that there are two VPN terminators, possibly in HA configuration. You'd need to check their configurations for how to enable a more seamless failover.

2
  • Thanks for answering. I tried pinging the VPN public address and that had not TTL deviation when the RDP drop occurred. The TTL was 241. Furthermore in the Fortinet firewall where the VPN is setup I am listening on 3 addresses as we have 3 different public ip's. However I removed all but 1 and still the RDP drops are happening. Commented May 21 at 12:27
  • I would agree that your screenshot indicates the path between the firewall and your end user computer is changing, which obviously drops the RDP session (source or destination IP changing interrupts the RDP session). I would check the logs on the firewall to see if there is anything that coincides with the time the RDP drops and the TTL changes. Then check the internet service for the end user device to see if it has a changing IP address or internet path. Commented May 21 at 14:16
1

Thanks for the help.

I found what was causing the problem. I had recently enlarged my IP scope and in doing so inadvertently included my servers IP address in the new scope without a reservation.

This meant that another pc could also get the same IP address as the server and this is what caused the drops I was experiencing.

I have since created a reservation for the serve IP address and all is working as expected.

1
  • 1
    Fits the indicates different end nodes in my answer... Also, your DHCP service or clients are not checking for duplicity, in violation of RFC 2131.
    – Zac67
    Commented May 22 at 11:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.