Vue d'ensemble GlobalProtect
GlobalProtect est la solution VPN de Palo Alto Networks intégrée directement dans PAN-OS. Elle ne se limite pas à un simple tunnel — c'est un système complet qui inclut l'identité, la posture du device (HIP), le routing sélectif et la visibilité App-ID sur les connexions distantes.
PortalPoint d'entrée unique — authentification, distribution de config agent
GatewayTermine le tunnel VPN — applique les Security Policies
AgentClient installé sur le poste — Windows, macOS, Linux, iOS, Android
HIPHost Information Profile — posture check avant accès
IPsec / SSL
App-ID sur VPN
User-ID intégré
HIP posture
MFA ready
Composants — Portal vs Gateway
CLIENT (agent GP installé)
│
│ 1. HTTPS → Portal (authentification + download config)
▼
┌─────────────────────────────────────┐
│ PORTAL (firewall Palo Alto) │
│ · Authentifie l'utilisateur │
│ · Distribue la config agent │
│ (liste des Gateways, tunnel mode,│
│ split tunnel rules, HIP policy) │
└─────────────────────────────────────┘
│
│ 2. IPsec ou SSL/TLS → Gateway
▼
┌─────────────────────────────────────┐
│ GATEWAY (firewall Palo Alto) │
│ · Termine le tunnel VPN │
│ · Applique Security Policies │
│ · App-ID, User-ID, Threat Prev. │
│ · Vérifie HIP (posture device) │
│ · Assigne IP pool au client │
└─────────────────────────────────────┘
│
▼
Réseau interne / Internet
Portal et Gateway peuvent être sur le même firewall (cas courant) ou sur des firewalls distincts (large scale). Le Portal est contacté en premier, une seule fois pour récupérer la config. Le Gateway est contacté à chaque connexion VPN.
Protocoles de tunnel
| Protocole | Port | Usage | Avantage |
|---|
| IPsec (IKEv2) |
UDP 4500 / 500 |
Défaut si possible |
Performance maximale, chiffrement natif |
| SSL/TLS |
TCP 443 |
Fallback si IPsec bloqué |
Passe les firewalls restrictifs, proxies |
GP essaie IPsec en premier, bascule automatiquement sur SSL si échec. Ce comportement est configurable dans le profil agent.
Modes de connexion
| Mode | Déclenchement | Cas d'usage |
|---|
| On-demand |
L'utilisateur se connecte manuellement |
Accès occasionnel au réseau interne |
| Pre-logon |
Avant l'ouverture de session Windows |
GPO, scripts de login, authentification machine |
| Always-on |
Automatique, permanent, ne peut pas être coupé |
Compliance obligatoire, zero trust total |
| User-logon |
Après ouverture de session utilisateur |
Cas standard entreprise |
En Full Tunnel, tout le trafic du client — interne ET internet — passe par le tunnel VPN vers le Gateway Palo Alto. Le client n'a plus de route directe vers internet.
Principe — tout passe par le Gateway
CLIENT (poste distant)
│
│ ← TOUT le trafic entre dans le tunnel
│ (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 ET 0.0.0.0/0)
▼
TUNNEL IPsec/SSL
│
▼
GATEWAY PALO ALTO (siège)
├── Trafic vers réseau interne → routé en interne
└── Trafic vers Internet (YouTube, etc.) → sort par le FW du siège
(inspecté, logué, filtré)
RÉSULTAT :
Client distant Siège
───────── ──────────────────────────
0.0.0.0/0 → tunnel GP → FW Palo Alto → Internet
10.0.0.0/8 → tunnel GP → réseau interne
Ce que voit la table de routage du client
! AVANT connexion GP (client normal)
Destination Gateway Interface
0.0.0.0/0 192.168.1.1 eth0 ← route par défaut locale
192.168.1.0/24 directly eth0
! APRÈS connexion GP Full Tunnel
Destination Gateway Interface
0.0.0.0/0 10.100.0.1 gpd0 ← route par défaut → tunnel GP !
10.0.0.0/8 10.100.0.1 gpd0 ← réseau interne → tunnel GP
192.168.1.0/24 directly eth0 ← réseau local direct (pour accès physique)
! gpd0 = interface virtuelle créée par l'agent GP
! 10.100.0.1 = IP du Gateway dans le tunnel
Avantages du Full Tunnel
- ✓ Visibilité totale — tout le trafic internet du remote worker est inspecté par le FW (App-ID, Threat Prevention, URL Filtering)
- ✓ Compliance maximale — aucun trafic n'échappe à la politique de sécurité de l'entreprise
- ✓ Simplicité de config — pas de règles split à maintenir, une seule route par défaut
- ✓ User-ID fiable — tout le trafic passe par le FW, mapping utilisateur parfait
- ✓ Posture Zero Trust — idéal avec Always-on, le poste est toujours sous contrôle
Inconvénients du Full Tunnel
- ✗ Bande passante — tout le trafic internet du user transite par le siège, surcharge le lien et le Gateway
- ✗ Latence — YouTube, Teams, Zoom passent par le siège → double saut réseau → dégradation qualité
- ✗ Coût infrastructure — le Gateway doit supporter tout le trafic de tous les remote workers
- ✗ SaaS dégradé — Microsoft 365, Salesforce, etc. voient leur performance impactée par le hairpin
Configuration Portal — Full Tunnel
! Network → GlobalProtect → Gateways → Agent → Client Settings
! Split Tunnel tab → Access Routes
! Pour Full Tunnel : NE PAS configurer de routes d'exclusion
! La route par défaut 0.0.0.0/0 est automatiquement poussée
Access Route :
Include 0.0.0.0/0 ← TOUT le trafic dans le tunnel
! OU via CLI (show running config) :
set network tunnel global-protect-app-ipsec-tunnel-gp-gw
tunnel-interface tunnel.1
local-address ip 203.0.113.1
peer-address ip any
! IP pool assigné aux clients
set network globalprotect gateways entry GP-GW
tunnel ip-pool 10.100.0.0/22 ← IPs attribuées aux clients VPN
En Split Tunnel, seul le trafic destiné aux ressources internes passe par le tunnel VPN. Le trafic internet va directement depuis le poste client, sans passer par le siège. C'est le mode le plus courant en entreprise aujourd'hui.
Principe — trafic sélectif dans le tunnel
CLIENT (poste distant)
│
├── Trafic 10.0.0.0/8 ─────────────────────► TUNNEL → Réseau interne
├── Trafic 172.16.0.0/12 ───────────────────► TUNNEL → Serveurs internes
│
└── Trafic Internet (YouTube, Teams, etc.) ──► Internet DIRECT
(bypass du tunnel)
TABLE DE ROUTAGE CLIENT :
─────────────────────────────────────────────
Destination Interface Via
10.0.0.0/8 gpd0 tunnel GP ← internal only
172.16.0.0/12 gpd0 tunnel GP ← internal only
0.0.0.0/0 eth0 192.168.1.1 ← internet local direct
Les 3 méthodes de Split Tunnel sur Palo Alto
| Méthode | Basé sur | Granularité | Cas d'usage |
|---|
| Access Routes |
Préfixes IP (Include / Exclude) |
Réseau |
Exclure des subnets internes ou inclure uniquement certains |
| Domain & Application |
FQDN / App-ID |
Application |
Exclure Office 365, Zoom, etc. du tunnel |
| Video Streaming |
Catégorie URL |
Contenu |
Exclure automatiquement le streaming vidéo |
Méthode 1 — Access Routes (Include / Exclude)
! Network → GlobalProtect → Gateways → Agent → Client Settings → Split Tunnel
! Option A : Include uniquement les réseaux internes
Include List :
10.0.0.0/8 ← réseau interne principal
172.16.0.0/12 ← DMZ / serveurs
192.168.100.0/24 ← VLAN management
! → internet va directement sans passer par le tunnel
! Option B : Include 0.0.0.0/0 (tout) puis Exclude certains subnets
Include List :
0.0.0.0/0 ← tout dans le tunnel par défaut
Exclude List :
8.8.8.8/32 ← exclure DNS public Google
13.107.0.0/14 ← exclure Microsoft 365
52.96.0.0/14 ← exclure Exchange Online
! → tout passe par tunnel SAUF les exclusions
Méthode 2 — Domain & Application Based Split Tunnel
! PAN-OS 9.1+ — Split tunnel basé sur FQDN et App-ID
! Network → GlobalProtect → Gateways → Agent → Split Tunnel → Domain and Application
! Exclure des domaines du tunnel (traffic va directement)
Exclude Domains :
*.microsoft.com
*.office365.com
*.zoom.us
*.teams.microsoft.com
! Exclure des applications par App-ID
Exclude Applications :
ms-office365
zoom
webex
! Note : nécessite agent GP 5.1+ et PAN-OS 9.1+
! Le DNS resolution se fait AVANT la décision de routing split
Avantages du Split Tunnel
- ✓ Performance SaaS — Teams, Zoom, Office 365 vont directement, latence optimale
- ✓ Bande passante Gateway — réduite significativement, meilleur scaling
- ✓ Expérience utilisateur — navigation internet fluide même avec VPN actif
- ✓ Coût infrastructure — Gateway moins sollicité, hardware moins dimensionné
Inconvénients du Split Tunnel
- ✗ Visibilité réduite — trafic internet du user non inspecté par le FW d'entreprise
- ✗ Risque exfiltration — un malware peut sortir directement par internet sans passer par les contrôles
- ✗ Maintenance des règles — les listes include/exclude doivent être maintenues à jour
- ✗ Compliance — certains secteurs (finance, santé) imposent Full Tunnel pour raisons réglementaires
Le choix entre Full Tunnel et Split Tunnel est une décision architecturale qui dépend du profil de risque, des contraintes réglementaires et de l'expérience utilisateur attendue.
🔴 Full Tunnel
- Tout le trafic passe par le FW d'entreprise
- Visibilité et contrôle total (App-ID, URL Filter)
- Compliance maximale (DORA, NIS2, secteur financier)
- Idéal avec Always-on / Zero Trust
- Performance dégradée pour SaaS et streaming
- Gateway plus sollicité, coût infra élevé
- Simple à configurer (une route 0.0.0.0/0)
🟢 Split Tunnel
- Seul le trafic interne passe par le tunnel
- Visibilité limitée sur le trafic internet
- Performance SaaS optimale (Teams, Zoom, O365)
- Bande passante Gateway réduite
- Risque : trafic malveillant peut sortir directement
- Maintenance des listes include/exclude nécessaire
- Plus complexe à bien configurer
Tableau de décision — quand choisir quoi
| Critère | Full Tunnel | Split Tunnel |
|---|
| Secteur financier / réglementé |
✓ Recommandé |
⚠ Risque compliance |
| Usage intensif Teams / Zoom / O365 |
✗ Latence élevée |
✓ Optimal |
| Posture Zero Trust stricte |
✓ Idéal |
~ Possible avec HIP |
| Grand nombre d'utilisateurs distants |
✗ Scaling difficile |
✓ Meilleur scaling |
| Visibilité totale sur le trafic |
✓ Complet |
✗ Partiel |
| Expérience utilisateur |
✗ Ralentissements possibles |
✓ Fluide |
| Simplicité opérationnelle |
✓ Simple |
~ Maintenance règles |
Le meilleur des deux mondes — Split Tunnel + Prisma Access
La réponse architecturale moderne au dilemme Full vs Split Tunnel est Prisma Access (SASE) :
CLIENT
│
├── Trafic interne ──────► Tunnel GP → Gateway on-prem
│
└── Trafic internet ──────► Prisma Access (cloud FW)
↓
App-ID, URL Filter, Threat Prev.
sur le trafic internet AUSSI
RÉSULTAT : Performance split tunnel + Visibilité full tunnel
C'est exactement le domaine "Modernizing Branches" et "SSE" du parcours PSE Architect.
Configuration complète d'un déploiement GlobalProtect — Portal, Gateway, IP Pool, tunnel interface et profil agent.
Étape 1 — Interface tunnel
! Network → Interfaces → Tunnel → Add
Interface Name : tunnel.1
Comment : GlobalProtect VPN Tunnel
Virtual Router : default
Security Zone : VPN ← zone dédiée pour les clients GP
IP Address : pas d'IP requise sur l'interface tunnel elle-même
Étape 2 — Gateway
! Network → GlobalProtect → Gateways → Add
Name : GP-GATEWAY
Interface : ethernet1/1 ← interface externe (internet)
IP Address : 203.0.113.1 ← IP publique du Gateway
! Tunnel Settings
Tunnel Interface : tunnel.1
IP Pool : 10.100.0.0/22 ← pool d'IPs pour les clients (1022 IPs)
DNS Servers : 10.0.0.53 ← DNS interne poussé aux clients
DNS Suffix : corp.example.lu
! Authentication
Authentication Profile : GP-AUTH-PROFILE ← LDAP/RADIUS/SAML
Étape 3 — Portal
! Network → GlobalProtect → Portals → Add
Name : GP-PORTAL
Interface : ethernet1/1
IP Address : 203.0.113.1 ← même IP que le Gateway (cas commun)
! Agent tab → Agent Config
Gateways : GP-GATEWAY ← liste des gateways distribués aux clients
Connect Method : user-logon ← ou pre-logon / always-on
! Client Settings → Split Tunnel tab
! === FULL TUNNEL ===
Access Route : Include 0.0.0.0/0
! === SPLIT TUNNEL (exemple) ===
Access Route : Include 10.0.0.0/8
Include 172.16.0.0/12
! → internet va directement, interne passe par tunnel
Étape 4 — Security Policy pour les clients GP
! Policies → Security → Add
! Règle 1 : VPN → Internal (accès aux ressources)
Name : GP-to-Internal
Source Zone : VPN ← zone des clients GP
Dest Zone : Trust ← réseau interne
Source IP : 10.100.0.0/22 ← IP pool GP
Application : any ← ou restreindre par App-ID
Action : Allow
Profile : GP-Security-Profile ← Threat Prev + URL Filter
! Règle 2 (Full Tunnel uniquement) : VPN → Internet
Name : GP-to-Internet
Source Zone : VPN
Dest Zone : Untrust
Action : Allow
Profile : GP-Security-Profile
Le Host Information Profile (HIP) est le mécanisme de vérification de posture du device avant d'accorder l'accès VPN. C'est un composant clé de l'approche Zero Trust de GlobalProtect.
Qu'est-ce que HIP ?
Avant d'accéder aux ressources internes, l'agent GP collecte des informations sur l'état du poste et les envoie au Gateway. Le Gateway applique des HIP Profiles dans les Security Policies pour conditionner l'accès.
AntivirusInstallé, actif, signatures à jour
OS PatchVersion OS, derniers patches appliqués
Disk EncryptionBitLocker, FileVault actifs
FirewallFirewall local activé
DomainMembre du domaine AD
CertificateCertificat machine valide (ADCS)
Flow HIP — étapes de vérification
Agent collecte les informations HIP
L'agent GP scanne le poste : AV, patches, chiffrement, certificats, membership AD. Fréquence configurable (défaut 60 min).
HIP Report envoyé au Gateway
L'agent envoie un rapport HIP au Gateway après l'établissement du tunnel.
Gateway évalue le HIP Profile
Le Gateway compare le rapport aux HIP Profiles configurés. Un HIP Profile est un ensemble de conditions (ex: AV actif ET patches OK).
Security Policy appliquée selon le HIP
Les règles de sécurité peuvent référencer le HIP Profile. Accès complet si compliant, accès réduit ou refusé sinon.
Exemple — politique différenciée selon posture
! Objects → GlobalProtect → HIP Profiles
! Profil 1 : poste compliant
HIP Profile : Compliant-Device
Match : antivirus is-installed AND real-time-protection enabled
AND disk-backup last-backup-time within 7 days
AND patch-management is-installed
! Profil 2 : poste non compliant
HIP Profile : Non-Compliant
Match : NOT Compliant-Device
! Security Policies avec HIP
Rule 1 : Source=VPN, Dest=Trust, HIP=Compliant-Device → Allow (accès complet)
Rule 2 : Source=VPN, Dest=Quarantine, HIP=Non-Compliant → Allow (accès limité)
Rule 3 : Source=VPN, Dest=Trust, HIP=Non-Compliant → Deny (bloqué)
HIP + ADCS — authentification par certificat machine
! Scénario : pre-logon avec certificat machine émis par ADCS
! Le poste s'authentifie AVANT le login user via son certificat
! 1. ADCS émet un certificat machine via GPO (auto-enrollment)
! 2. L'agent GP utilise ce certificat pour s'authentifier au Portal
! 3. HIP Profile vérifie la présence du certificat machine valide
HIP Profile : Domain-Member
Match : certificate issuer contains "corp-CA"
AND domain member-of "corp.example.lu"
! Résultat : seuls les postes membres du domaine avec cert valide
! peuvent établir le tunnel → zero trust device authentication
⚡ Piège #1 — DNS Split Tunnel : attention aux fuites DNS
En Split Tunnel, si le DNS interne est poussé aux clients mais que la route vers le DNS interne n'est pas dans l'Include List, les requêtes DNS vont par internet — fuite DNS. Toujours vérifier que le subnet du serveur DNS interne est dans l'Include List ou que le DNS est joignable via le tunnel.
! Problème typique :
! DNS poussé : 10.0.0.53
! Include List : 192.168.0.0/16 seulement
! → 10.0.0.53 inaccessible → client utilise DNS public → fuite
! Solution : ajouter 10.0.0.0/8 dans l'Include List
⚡ Piège #2 — Portal et Gateway sur la même IP : ordre des règles NAT
Si Portal et Gateway partagent la même IP publique sur le même firewall, les règles de sécurité et NAT doivent distinguer le trafic Portal (HTTPS/443) du trafic tunnel Gateway (IPsec UDP 4500). Un conflit de règles peut empêcher les connexions de s'établir.
⚡ Piège #3 — Always-on sans split tunnel d'urgence
En mode Always-on, si le Gateway est injoignable (panne, maintenance), le poste peut se retrouver sans accès réseau du tout. Toujours configurer un Connect Before Logon ou une exclude list pour le trafic critique (ex: adresses IP des passerelles de l'entreprise).
⚡ Piège #4 — HIP Report : délai initial
Lors de la première connexion GP, le HIP Report n'est pas immédiatement disponible. Il y a un délai de quelques secondes entre l'établissement du tunnel et la réception du premier HIP Report. Pendant ce délai, les règles qui requièrent un HIP Profile peuvent bloquer le trafic. Utiliser un profil HIP "Any" en rule de fallback pour éviter ce blocage temporaire.
⚡ Piège #5 — Split Tunnel Domain-based : résolution DNS préalable
Le split tunnel basé sur les domaines (FQDN) fonctionne uniquement si le DNS résout le FQDN avant que l'agent décide par où router le trafic. Si le DNS échoue ou retourne une IP inconnue, le trafic peut passer dans le tunnel alors qu'il devrait bypasser. Tester systématiquement avec nslookup depuis le client connecté.
✓ Bonne pratique — tester les deux modes en lab avant déploiement
Utiliser show global-protect-gateway current-user et show global-protect-gateway statistics pour valider le mode actif et les routes poussées aux clients.
! Vérifications essentielles
show global-protect-gateway current-user
show global-protect-gateway statistics
show routing route type vpn ← routes GP dans la table
debug globalprotect gateway statistics
Cliquer sur une carte pour révéler la réponse.
En Full Tunnel, quelle route est poussée au client ?
0.0.0.0/0 — toute la table de routage du client pointe vers l'interface tunnel GP. Tout le trafic, y compris internet, passe par le Gateway.
Cliquer pour révéler
Quelle est la différence entre Portal et Gateway ?
Le Portal authentifie et distribue la config (liste des Gateways, split tunnel rules). Le Gateway termine le tunnel VPN et applique les Security Policies.
Cliquer pour révéler
GP essaie quel protocole en premier — IPsec ou SSL ?
IPsec (IKEv2) en premier — UDP 4500/500. Bascule automatiquement sur SSL/TLS (TCP 443) si IPsec est bloqué par un firewall intermédiaire.
Cliquer pour révéler
Qu'est-ce qu'un HIP Profile et où est-il appliqué ?
Un HIP Profile est un ensemble de conditions de posture device (AV, patches, chiffrement…). Il est référencé dans les Security Policies pour conditionner l'accès selon l'état du poste.
Cliquer pour révéler
Quel mode de connexion GP permet l'auth machine AVANT le login user ?
Pre-logon — le tunnel s'établit avant l'ouverture de session Windows, avec le certificat machine. Permet les GPO et scripts de login via VPN.
Cliquer pour révéler
En Split Tunnel, le trafic internet du client est-il inspecté par le FW ?
Non — le trafic internet bypasse le tunnel et sort directement depuis le réseau local du client. Seul le trafic vers les Include routes passe par le Gateway Palo Alto.
Cliquer pour révéler
Quelle solution Palo Alto combine visibilité full tunnel et performance split tunnel ?
Prisma Access (SASE) — le trafic internet passe par un FW cloud Palo Alto (inspecté), le trafic interne par le Gateway on-prem. Meilleur des deux mondes.
Cliquer pour révéler
Quel piège guette le Split Tunnel Domain-based ?
La résolution DNS doit se faire avant la décision de routage. Si le DNS échoue, l'agent ne peut pas savoir si le trafic doit bypasser ou entrer dans le tunnel — risque de mauvais routage.
Cliquer pour révéler