How to detect when Global Protect client fails to establish IPSec VPN tunnel with the GP Gateway
103837
Created On 09/25/18 19:50 PM - Last Modified 04/27/20 18:03 PM
Symptom
Environment
- Pan-OS
- Global Protect
Resolution
If one wants to monitor when GlobalProtect clients fail to form IPSec tunnel and have ability to historically track down such conditions, it can be done using one of the two options explained below.
When the client connects to the Gateway via SSL, firewall generates the following entry in System Log:
2016/04/19 12:41:13 info globalp GP-Gat globalp 0 GlobalProtect gateway client switch to SSL tunnel mode succeeded. User name: client2, Private IP: 10.225.18.2.
So the first option would be to monitor system logs and detect this like entry as an indication of SSL VPN being established instead of IPSec VPN.
Furthermore, if rasmgr process is set to debug level (debug rasmgr on debug) the following lines are generated in rasmgr.log file when client forms IPSec tunnel:
2016-04-19 12:43:11.127 +0200 debug: sslvpn_tunnel_install_esp(src/rasmgr_sslvpn.c:2738): Installing GW Tunnel, indicate to keymgr 2016-04-19 12:43:23.129 +0200 debug: rasmgr_sslvpn_refresh(src/rasmgr_sslvpn.c:1901): portal GP-Gateway-N, user client2
When client falls back to SSL VPN tunnel, the following lines are generated in rasmgr.log file:
2016-04-19 12:41:13.472 +0200 debug: rasmgr_sysd_update_obj(src/rasmgr_sysd_if.c:1099): change tunnel.ssl.cmd.msg 2016-04-19 12:41:24.262 +0200 debug: rasmgr_sslvpn_refresh(src/rasmgr_sslvpn.c:1901): portal GP-Gateway-N, user client2
Additional Information
Here is some of the difference between the SSL connection VS IPSEC connection:
- If IPSec is enabled on the Gateway it has precedence over SSL tunnel
- There is no IKE negotiation as IPSec parameters are exchanged within SSL control session
- Client will try IPSec connection on port 4501 first (UDP encapsulated ESP packet)
- If there is no response from the gateway (traffic filtered?), client is falling back to SSL