Cannot use Palo Alto GlobalProtect VPN with CC (Reactive)

[TheVisualFeast]

Hi Guys,

 

Hopefully you can help me as I've been banging my head on this issue for a while since our company migrated to use Palo Alto's GlobalProtect for client access VPN's.

 

Connection is extremely unstable when using the VPN in conjunction with the Reactive algorithm within CC (even though it's turned off due to super turbo mode). I've been reading on these forums a few other people have similar issues.

I can however get this working and stable every time when using Preemptive, however my download speed goes from 360Mb/s to ~55mb/s.

 

Do you know what my options are or have any tricks up your sleeve so I can keep my download speed and connect using GlobalProtect? I've signed up for the DumaOS beta trial in case a change in OS addresses some bug or lack in functionality. I'm currently on 1.03.6h

 

Thanks,

Leigh

[Netduma Fraser]

Hey, welcome to the forum!

We are aware that some people had trouble when using reactive and the VPN, really the only solution is to use Preemptive as we're not making any more changes to the original firmware as we're moving forward with DumaOS. If you have DumaOS from our previous open beta you could try that, otherwise I'd suggest waiting for 3.0 and giving us feedback then as it'd be the ideal time to do so.

[TheVisualFeast]

Thanks for the information Fraser.

Do you have a link to the pre 3.0 DumaOS firmware I can use in the meantime?

[Netduma Fraser]

You'll need to sign up for that here first: https://netduma.com/r1-dumaos/

[TheVisualFeast]

Thanks for the information. Managed to upgrade the router, only to find the downstream speed was poor (limited to 150mbps) and the issue still persists.

I can get around the speed issue by disabling QoS, but GlobalProtect still doesn't work.

 

Alarmingly, I've been reading through a similar issue (

) 

This has not filled me with confidence. I can no longer achieve a stable connection using this VPN and now there is no workaround I can use in the current DumaOS.

 

Do you have any idea what's causing Duma to interfere with this VPN traffic? I can see this ticket has been open for 18 months, is there anything in 3.0 that addresses this? Currently have no way of connecting to work unless I go back to 1.x and turn on Preemptive.

 

Thanks

[Netduma Fraser]

I'm not sure if it was this VPN issue or a WiFi calling issue - which I think are actually related (I'm not a developer but I think it's dropping packets either because QoS doesn't deem it essential or to get higher speeds it drops what it thinks are unnecessary packets - take that with a pinch of salt) but we definitely resolved one of those fairly quickly in 3.0. If it's not fixed then it'll provide the perfect opportunity for you to provide feedback. I can't see it not being fixed due to the current need for it.

[TheVisualFeast]

Thanks Fraser, this leaves me in a bit of a quandary. More than happy to test and provide feedback, but given the current climate being able to work from home and remote in is essential. I suppose I'm faced with two options, please let me know which one is quickest/achievable.

I either roll back (possible?) to 1.03.6h and stick myself in preemptive, or do you have a 3.0 beta build I can test with the Palo Alto GlobalProtect VPN?

[Netduma Alex]

11 hours ago, TheVisualFeast said:

Thanks Fraser, this leaves me in a bit of a quandary. More than happy to test and provide feedback, but given the current climate being able to work from home and remote in is essential. I suppose I'm faced with two options, please let me know which one is quickest/achievable.

I either roll back (possible?) to 1.03.6h and stick myself in preemptive, or do you have a 3.0 beta build I can test with the Palo Alto GlobalProtect VPN?

No not yet, we will soon though, the 3.0 beta launch is so close I can almost taste it.

[TheVisualFeast]

Thanks Alex, well given my issue if there's anything you can do about my prioritisation, that would be greatly appreciated. In the spirit of identifying the issue and troubleshooting, I have some potentially interesting findings.

Comparing the logs, I can see keep alives are not getting through after initial connection, thus dropping the connection and trying again. This behaviour persists indefinitely.

06/10/0020 14:39:34.288 [Info ]: Gateway dc1-byod-gateway: Checking network availability and restoring VPN connection when network is available.
06/10/0020 14:39:37.728 [Info ]: Tunnel is restored.
06/10/0020 14:40:28.742 [Info ]: Tunnel is down due to keep-alive timeout.
06/10/0020 14:40:28.742 [Info ]: Gateway dc1-byod-gateway: Checking network availability and restoring VPN connection when network is available.
06/10/0020 14:40:32.241 [Info ]: Tunnel is restored.
06/10/0020 14:41:23.255 [Info ]: Tunnel is down due to keep-alive timeout.
06/10/0020 14:41:23.255 [Info ]: Gateway dc1-byod-gateway: Checking network availability and restoring VPN connection when network is available.
06/10/0020 14:41:26.774 [Info ]: Tunnel is restored.
06/10/0020 14:42:17.787 [Info ]: Tunnel is down due to keep-alive timeout.
06/10/0020 14:42:17.787 [Info ]: Gateway dc1-byod-gateway: Checking network availability and restoring VPN connection when network is available.
06/10/0020 14:42:21.232 [Info ]: Tunnel is restored.
06/10/0020 14:43:12.246 [Info ]: Tunnel is down due to keep-alive timeout.

So I suspect something is being filtered within the IPSec protocol itself. To test this I blocked UDP/4501 on my windows firewall and retested.

The PaloAlto client could not establish a tunnel using IPSec, so downgraded to SSL. This then worked and I have a stable tunnel.

 

I can probably live with this for the time being (and if anyone is troubleshooting a similar issue your VPN gateway must support SSL downgrade and be configured for this to work).  My question is whether this is a known issue and is it fixed in 3.0?

 

On a similar side note, for personal use I use IPVanish and had similar problems with that. The only way I could get this to work was to use ANY protocol except for IKEv2 (default on client installation). OpenVPN, L2TP, SSTP and PPTP all remain unaffected and establish a tunnel. Since IKE is part of IPSec I wonder if this is the issue with Duma?

 

[Netduma Fraser]

I'd suggest downgrading for the moment as it is so quickly if you would rather not use SSL. Thank you very much for that information, you may be on to something - I'll pass it onto the team.

[TheVisualFeast]

Thanks Fraser, could you confirm this is resolved in 3.0? 

[Netduma Fraser]

We haven't done anything regarding that as far as I'm aware but it still may be fixed through our general changes, best to let us know when you get in the beta.