Users successfully established Cloud VPN connections using Cisco Secure Client but were unable to access internal private resources after connection. The VPN tunnel appeared to be connected on the Secure Access side during backend checks, but internal network services remained inaccessible to connected users. This connectivity issue impacted user access to internal assets despite successful VPN authentication and tunnel establishment.
Cisco Secure Client
Network Tunnel Group on Secure Access
Palo Alto as Edge Firewall
Internal private network resources configuration
Secure access Remote VPN
The connectivity issue was resolved through a collaborative troubleshooting session and tunnel reset procedure on the Palo Alto firewall side.
Validate the current connectivity state and confirm that Secure Access-side tunnels are showing as connected in backend checks.
Take the packets on cloud native headend (CNHE) to ensure if the traffic is leaving and reaching to the Palo Alto .
No traffic was observed on the Palo Alto end.
Recommended to do the tunnel reset. Once the tunnel was reset, the user reconnected to the VPN using Secure Client to establish fresh tunnel connections through the reset infrastructure.
Following reconnection, we confirmed that internal resource access was restored and users could successfully reach internal network services through the VPN connection.
The root cause was related to tunnel state inconsistencies on the Palo Alto firewall side that prevented proper routing of internal traffic despite successful VPN authentication. The tunnel reset procedure cleared these state inconsistencies and restored proper connectivity paths for internal resource access.
| Revision | Publish Date | Comments |
|---|---|---|
1.0 |
08-May-2026
|
Initial Release |