Problem with Global Protect VPN (connection to my workplace)

[#1]

Hi Andrew,

Just to highlight that ChrisWoods' comment earlier about MTU sizes is a REALLY good one. My DM200 (which DIDN'T work) had a MTU size of 1492, but my new DrayTek has an MTU of 1442. So I strongly suspect that was my problem. if you haven't already - try modifying that value.

All the best,

Kris.

[#2]

Thanks Kris,

I’ve tried editing the MTU size to 1472, 1470, 1436, 1400 and 1000. Still not connecting to the VPN.

Regarding this comment:
“ one discussion elsewhere suggests forwarding port UDP 500 for IPSec and enabling ICMP reply to WAN echos ("Respond to Ping on Internet Port") and you should locate and disable any Netgear firewall or traffic filtering”
Are there security implications with this? Haven’t forwarded any ports before so not sure what it actually does.

Thanks,

Andrew

I should mention that I also had this same problem with the standard plus net router too.



Andrew

[#3]

---

@andrewgallagher wrote:
I’ve tried editing the MTU size to 1472, 1470, 1436, 1400 and 1000. Still not connecting to the VPN.

---

Rats. Did you run the ping tests while VPNed, manually adjusting the packet size to see at what point they're fragmented?

Regarding this comment:
“ one discussion elsewhere suggests forwarding port UDP 500 for IPSec and enabling ICMP reply to WAN echos ("Respond to Ping on Internet Port") and you should locate and disable any Netgear firewall or traffic filtering”
Are there security implications with this? Haven’t forwarded any ports before so not sure what it actually does.

---

I wouldn't be troubled by doing either. In fact on my other connection I explicitly requested the ISP enable WAN ICMP echo reply on their provided router as I use the feature for line monitoring. There's more than one way for a miscreant to do host discovery there, nmap doesn't need ICMP echo.

Likewise with port 500 UDP, if there's nothing on your machine waiting to handle ingress traffic on 500 UDP, any inbound packets go straight to oblivion (the case whenever the IPSec VPN client is not running to respond to any IKE traffic).

I should mention that I also had this same problem with the standard plus net router too.

---

That's curious. Same symptoms each time? I'd be interested to know what firewall and AV you're running on the PC, whether any VPN product works reliably at all (any of the OpenVPN, SSL or Torguard-protocol services), and what OS/network adapter/intermediate switch you have in your setup.

[#4]

Status update: I've had my VPN client changed to F5 (Edge Big IP) and my original client (Global Protect) has been removed. This has been a big step forward in that I can now connect to the VPN, and it appears to have been stable today.

However the speed isn't great. If I do a speed test connected by wifi or LAN cable I get 70-80Mbps down and 20Mbps up, but on teams/zoom calls the video is frozen most of th etime and the audio is generally passable. When I swap connections to be ing terhered to my mobile I get 18Mbps down and 7-8MBps up but get perfect audio and video.

Not sure if this is related to my previous VPN issue, but it has got me a bit closer to being able to work from hone using my boradband. I just need to swap connections when I have an important call...

Andrew

[#5]

That's interesting and denotes a possible issue with the PC, perhaps even the drivers you're using for your Ethernet adapter. I had major issues with recent releases of Intel ProSet drivers and, ironically, had to roll back to 2016/2017 WHQL drivers to eliminate them! Not beyond the realms of possibility that your NIC drivers or configuration is a big screwed up. I'd be tempted to uninstall the device and fully delete the driver infs from the machine, reboot then tether over USB and redownload the Microsoft issued drivers for the Ethernet chipset from Windows Update. I'd also try fully uninstalling and removing your firewall and AV software to see if that makes any difference to your connection reliability. I'd also consider resetting your winsock stack for good measure. This might require you to then reinstall and reconfigure your VPN clients.

Out of curiosity if you run a quality test using CloudFlare's speed test facility (which also measures jitter metric) what do your stats come out as? Have PN customer service mentioned anything about congestion in your area necessitating some traffic shaping? Just thinking aloud now...

[#6]

Thanks Chris,

The Cloudflare speed test is really interesting! I've attached the results. Speed is in the 90th percentile but can't tell whether latency or jitter are good or bad!

Andrew

[#7]

All seems respectable, and a very tight spread of speeds for that testing traffic. Is that while VPNed or direct?

Nowadays f5 proxies in a different way from GlobalProtect which is generally more router-friendly. That said, the software on your machine may still be causing issues. Another thing to try would be booting to a Linux live image (USB or CD), spinning up the Linux f5 client and testing speeds over that - and trying Zoom/Teams as available.

In Zoom there's also tech diagnostics available from the preferences while on a session, check those out...

It would be equal parts frustrating and and hilarious if, after all this, there was actually also some bizarre issue with how your static IP was being routed. There's always the option of requesting to be put back in the DHCP pool and do some testing, or request an IP in a totally different range.

I'd do the local PC stuff first and eliminate everything you possibly can, then pursue PN for technical assistance.