BOVPN dropping pings & slow to connect to remote desktop sessions

I setup a BOVPN between our NY office (M270 w/12.6.2.B631387) and CA office (T35 w/12.6.2.B631387) and am having some problems. The connection starts up OK and traffic flows, but connecting to a Remote Desktop session is very slow and when I ping a device across the BOVPN, I get some pings that respond with times about 90 - 110 msec as expected and some that just timeout. I have many more ping timeouts going from CA to NY than the other way around. The Internet connection in NY is Spectrum with 650/35Mbps and the connection in CA is Race Fiber with 100/100Mbps. Running speedtest.net shows these (or a little higher) as the speeds. I have tired both IKEv1 and IKEv2 on the Phase 1 settings with similar results. I have increase the NAT Traversal Keep-Alive from the default 20 to 40 seconds and same for the Dead Peer Detection which is using the default Traffic-Based type.

Any ideas what else to try or how to trouble shoot what might be happening?

-Landy

Comments

  • edited December 2020

    One other thing is that if the computers in the CA office use the Watchguard Mobil SSL VPN for a connection to the NY office, everything works as expected with no dropped packets and connections to Remote Desktop behaving as expected. That makes me think it is a Fireware setting issue and not something with the Internet connections at the two sides.

  • FYI - Fireware 12.6.2 U3 B631387 is not released for a T35.
    Fireware 12.5.5 Update 1 is the latest that I see for a T35.

    Ping times of 90 - 110 msec seem very long to me.
    Are you seeing this kind of response time delay when pinging to the firewall external IP addr from the other end?
    You can use tools such as Ping Plotter to see a graphic representation of continuous pings to an endpoint. This will show where the high latency and dropped packets are happening.
    Have 1 running to your remote firewall external interface IP addr and a 2nd one to something down the BOVPN.

    Verify that the Phase 2 proposal has "Force Key Expiration" set only to hours and that Traffic check box is not selected.

    RDP in the past didn't perform well through a BOVPN unless the endpoints were set to identify the Path MTU to use for sessions or have their MTUs set to 1400. I haven't tried this in a good while, but I suspect the there still might be an issue here.

    You can use Alan's PMTU script to change Windows so that it automatically
    identifies the correct MTU to use for a session.
    I have listed that script in this topic:

    Topic: IKEV2 sound
    https://community.watchguard.com/watchguard-community/discussion/comment/5280#Comment_5280

    Finally, you can always open a support incident to get help from a WG rep to try to help resolve this.

  • Bruce, you are correct about the version of Fireware on the T35. It is 12.5.5.B630561 as you said. I accidentally cut/pasted from the wrong Web UI screen when I was making the post!

    Thanks for the other thoughts. I will give Watchguard a call if I don't figure it out pretty quickly.

    -Landy

Sign In to comment.