SASE — Palo Alto + Netskope

SASE — Secure Access Service Edge

Terme créé par Gartner en 2019. SASE fusionne le networking (SD-WAN, optimisation WAN) et la sécurité cloud (CASB, SWG, ZTNA, FWaaS) en une seule plateforme cloud-native. L'idée : la sécurité suit l'utilisateur, pas le datacenter.

Principe fondamental : Avant SASE, le trafic revenait au datacenter pour être inspecté puis ressortait. Avec SASE, l'inspection se fait dans le cloud, près de l'utilisateur — moins de latence, meilleure scalabilité.

Les 5 composants SSE (Security Service Edge)

Le SSE est la partie sécurité du SASE. Netskope est un fournisseur SSE.

🔍

CASB

Cloud Access Security Broker — visibilité et contrôle sur les SaaS (M365, Salesforce, Box…)

🌐

SWG

Secure Web Gateway — filtrage URL, anti-malware, inspection TLS du trafic web

🔑

ZTNA

Zero Trust Network Access — accès applicatif granulaire, remplace le VPN traditionnel

🛡️

FWaaS

Firewall-as-a-Service — L4/L7 dans le cloud, règles centralisées

🕵️

DLP

Data Loss Prevention — empêche la fuite de données sensibles vers le cloud

SASE vs Architecture traditionnelle

🏢 Architecture traditionnelle (hub & spoke)

Trafic remote user → VPN → DC → inspection → Internet
Hair-pinning : latence élevée
Scalabilité limitée par le firewall physique
Sécurité = périmètre réseau
Visibilité limitée sur le SaaS

☁️ Architecture SASE

Trafic remote user → PoP Netskope le plus proche → Internet
Inspection dans le cloud, sortie locale
Scalabilité cloud native (100+ PoPs)
Sécurité = identité + contexte + device
Visibilité totale SaaS/web/cloud

Positionnement des acteurs

Fournisseur	Produit SASE/SSE	Points forts	Intégration Palo Alto
Netskope	SSE natif	CASB leader, NPA (ZTNA), visibilité SaaS profonde	IPSec tunnel / GRE depuis Palo Alto PBF
Zscaler	ZIA + ZPA	SWG leader, ZPA (ZTNA), large réseau PoP	IPSec/GRE tunnel depuis Palo Alto ou Panorama
Prisma Access	Palo Alto SASE	SASE natif Palo Alto, intégration Panorama, ML-based	Intégré nativement (même vendor)
Cloudflare One	SSE + Magic WAN	Réseau mondial Cloudflare, CASB + ZTNA	IPSec ou Cloudflare Tunnel

Dans notre architecture : Le Palo Alto est le firewall on-premise (terminaison VPN, PBF), Netskope est le SSE cloud. Les deux coexistent : Palo Alto pour le contrôle périmètre + GP VPN, Netskope pour l'inspection web/cloud et la visibilité SaaS.

Modes de déploiement Netskope

Mode	Comment ça marche	Cas d'usage
Client NPA	Agent installé sur le poste, steering direct vers PoP Netskope	BYOD, postes managés, ZTNA
IPSec Tunnel notre archi	Tunnel IPSec depuis le Palo Alto vers Netskope PoP	Trafic VPN centralisé, steering depuis le FW
GRE Tunnel	Tunnel GRE depuis le Palo Alto ou un routeur	Alternative IPSec, sans chiffrement natif
Proxy explicite	PAC file / proxy configuré sur le navigateur	Environnements sans agent, anciens systèmes
API CASB	Connexion API directe aux SaaS (pas inline)	Audit, DLP sur données at rest dans SaaS

Vue d'ensemble de l'architecture

Architecture réelle basée sur l'investigation d'un ticket support. Deux GlobalProtect Gateways, deux tunnels IPSec Netskope (AMS + FRA), PBF pour le steering du trafic web.

Récapitulatif des composants

Composant	Rôle	IPs clés	Interface
Palo Alto NGFW	Terminaison VPN, Security Policy, NAT, PBF vers Netskope	158.64.24.14/28 158.64.24.8/32	ae3.80 (vr_prod)
GP Gateway 1	Endpoint VPN principal pour les clients distants	158.64.24.14	tunnel.100
GP Gateway 2	Endpoint VPN secondaire / failover	158.64.24.8	tunnel.102
Netskope AMS	PoP Amsterdam — inspection + sortie Internet primaire	NH: 10.161.6.216 Exit: 163.116.240.135	tunnel.1
Netskope FRA	PoP Frankfurt — inspection + sortie Internet secondaire	NH: 10.178.6.216 Exit: 163.116.176.115	tunnel.2

Récapitulatif des plages IP

Plage	Usage	Propriétaire
158.64.4.0/24	Plage IP publique principale entreprise	Palo Alto
158.64.24.14/32	GlobalProtect Gateway 1 (entrée VPN)	Palo Alto
158.64.24.8/32	GlobalProtect Gateway 2	Palo Alto
10.250.x.x	Pool IP clients VPN GlobalProtect	Palo Alto
163.116.240.135	Sortie Internet via Netskope AMS	Netskope
163.116.176.115	Sortie Internet via Netskope FRA	Netskope
10.161.6.216	Next-hop tunnel IPSec Netskope AMS	Netskope
10.178.6.216	Next-hop tunnel IPSec Netskope FRA	Netskope

GlobalProtect — VPN Palo Alto

GlobalProtect est la solution VPN/ZTNA de Palo Alto Networks. Elle se compose d'un Portal (authentification, distribution de config) et d'une ou plusieurs Gateways (terminaison des tunnels).

Composants GlobalProtect

🚪 GP Portal

Point d'entrée unique pour les clients
Authentification (AD/LDAP/SAML/MFA)
Distribue la liste des Gateways au client
Pousse la config de l'agent
Gère les profils HIP (Host Info Profile)

🔒 GP Gateway

Terminaison des tunnels IPSec/SSL
Attribution d'IP aux clients (pool 10.250.x.x)
Application des Security Policies
Split tunneling ou full tunnel
Peut être externe (Internet) ou interne (LAN)

💻 GP Client (agent)

Installé sur Windows/macOS/Linux/iOS/Android
Contacte le Portal pour s'authentifier
Sélectionne la meilleure Gateway (latence)
Monte le tunnel vers la Gateway choisie
Collecte HIP (posture du poste)

Notre configuration — 2 Gateways sur ae3.80

Gateway	IP publique	Interface tunnel	Rôle
Gateway 1	158.64.24.14/28	tunnel.100	Primaire — connexion principale des clients VPN
Gateway 2	158.64.24.8/32	tunnel.102	Secondaire — failover ou usage spécifique

Établissement du tunnel GP — étapes

Connexion au Portal

Le client contacte le Portal (HTTPS) → authentification AD/SAML/MFA → reçoit la liste des Gateways disponibles avec leurs priorités

↓

Sélection de la Gateway

Le client fait un ping RTT vers chaque Gateway → sélectionne la plus rapide (ou priorité forcée par config) → ici 158.64.24.14

↓

Établissement du tunnel

IPSec IKEv2 ou SSL/TLS vers la Gateway choisie → attribution d'une IP du pool 10.250.x.x → interface virtuelle créée sur le poste

↓

HIP Check (optionnel)

La Gateway vérifie la posture du poste (antivirus à jour, disque chiffré, patch level) → autorise ou bloque selon la Security Policy HIP

↓

Trafic en cours

Tout le trafic passe par le tunnel → appliqué aux Security Policies + NAT + PBF → redirection vers Netskope pour HTTP/HTTPS

Split Tunnel vs Full Tunnel

✂️ Split Tunnel

Seul le trafic destiné au réseau interne passe par le VPN
Internet va directement depuis le poste
Moins de charge sur le Palo Alto
Risque : trafic Internet non inspecté
Netskope client sur le poste peut compenser

🔒 Full Tunnel (notre archi)

Tout le trafic passe par le tunnel VPN
Le Palo Alto voit et contrôle 100% du trafic
PBF redirige HTTP/HTTPS vers Netskope
L'utilisateur sort par 163.116.x.x (Netskope)
Visibilité totale + inspection CASB/SWG

Pourquoi l'utilisateur voit 2 IPs différentes : Les deux tunnels Netskope (AMS + FRA) font du load balancing. Selon quelle connexion est active au moment de la requête, l'IP de sortie est soit 163.116.240.135 (AMS) soit 163.116.176.115 (FRA). Ce n'est pas un problème — c'est la haute disponibilité Netskope.

Netskope — SASE / SSE

Netskope est leader dans le carré magique Gartner SSE. Sa plateforme cloud (Netskope Security Cloud) intègre CASB, SWG, ZTNA (NPA), DLP, et threat protection sur un réseau mondial de PoPs.

Architecture Netskope Cloud

🔍

CASB Inline

Contrôle en temps réel des SaaS (M365, Google, Salesforce) via proxy

🌐

SWG

Filtrage web, catégorisation URL, inspection TLS, anti-malware

🔑

NPA (ZTNA)

Netskope Private Access — accès applicatif zero trust, remplace VPN

🕵️

DLP

Prévention fuite de données — inline + API pour données at rest

🦠

Threat Prot.

Anti-malware, sandboxing, protection zero-day dans le trafic web

📊

SSPM

SaaS Security Posture Mgmt — audit de configuration SaaS

Les deux tunnels IPSec Netskope

☁️ tunnel.1 — Amsterdam (AMS)

Next-hop: 10.161.6.216
IP de sortie: 163.116.240.135
Plage: 163.116.240.0/24
Datacenter primaire (Europe Nord)
AS55256 — Netskope Inc.

☁️ tunnel.2 — Frankfurt (FRA)

Next-hop: 10.178.6.216
IP de sortie: 163.116.176.115
Plage: 163.116.176.0/24
Datacenter secondaire (Europe Centre)
AS55256 — Netskope Inc.

Pourquoi deux datacenters ?

Haute disponibilité : Si un PoP tombe, le trafic bascule automatiquement sur l'autre tunnel
Load balancing : Le Palo Alto peut répartir la charge entre les deux tunnels (ECMP ou PBF avec tracking)
Latence : Le PoP le plus proche répond plus vite → meilleure expérience utilisateur
Regulatory : Certains flux peuvent être forcés sur un datacenter spécifique pour conformité data residency

Ce que Netskope inspecte sur notre trafic

Type de trafic	Inspection Netskope	Action possible
HTTP/HTTPS vers SaaS	CASB inline — identification de l'app, user, activité	Block, alert, DLP, watermark
Navigation web générale	SWG — catégorie URL, réputation, contenu	Block par catégorie, coaching, alert
Upload vers cloud storage	DLP — pattern matching sur le contenu	Block si données sensibles, quarantaine
Malware download	Threat Protection — signature + sandbox	Block, sandboxing, alert SOC
RFC 1918 (interne)	❌ Pas inspecté — no-PBF sur le Palo	Trafic reste interne direct

NAT Palo Alto vs NAT Netskope

Question fréquente : pourquoi les deux font du NAT ?

Qui	Type de NAT	Pourquoi
Palo Alto	Source NAT (SNAT)	Traduit l'IP privée 10.250.x.x en IP publique 158.64.x.x pour le trafic NON-Netskope (interne, RFC1918). Le trafic vers Netskope part avec l'IP du tunnel — pas besoin de SNAT.
Netskope	Source NAT (SNAT)	Traduit l'IP interne reçue dans le tunnel en sa propre IP publique (163.116.x.x) pour sortir vers Internet. C'est Netskope qui "représente" l'utilisateur sur Internet.

Résumé : Palo fait du SNAT pour le trafic interne. Netskope fait du SNAT pour sortir sur Internet. Les deux sont complémentaires et non redondants.

Vérification ASN Netskope

# Vérification depuis routeviews ou bgp.he.net
# AS55256 = Netskope Inc.
whois -h whois.radb.net AS55256

# Plages annoncées par Netskope AS55256
# 163.116.240.0/24 → Amsterdam
# 163.116.176.0/24 → Frankfurt

# Depuis la console Netskope Admin → Settings → Security Cloud Platform
# → IP Allocations → voir toutes les IPs de sortie par PoP

Policy Based Forwarding (PBF)

Le PBF (Policy Based Forwarding) sur Palo Alto est l'équivalent du PBR Cisco — il redirige le trafic sur des critères de policy (src, dst, port, app, zone) plutôt que sur la table de routage standard.

Principe dans notre archi : Le trafic HTTP/HTTPS des clients VPN (10.250.x.x) est intercepté par le PBF et forcé dans les tunnels Netskope, indépendamment de ce que dit la table de routage.

Logique PBF — Règles NETSKOPE

Priorité	Source	Destination	Application	Action
1 (no-pbf)	10.250.x.x (GP pool)	RFC 1918 (10/8, 172.16/12, 192.168/16)	any	No PBF → route normale
2	10.250.x.x (GP pool)	any (Internet)	web-browsing ssl	Forward → tunnel.1 (Netskope AMS)
3 (failover)	10.250.x.x (GP pool)	any (Internet)	web-browsing ssl	Forward → tunnel.2 (Netskope FRA)

Les règles PBF sont évaluées dans l'ordre. La règle no-pbf RFC1918 passe en premier → les IP privées ne partent jamais vers Netskope.

PBF vs Routage standard — différence clé

📍 Routage standard (FIB lookup)

Consultation de la table de routage (FIB)
Basé uniquement sur IP destination
Default route → gateway WAN habituelle
Tout le trafic Internet sortirait par ae3.80
Pas de distinction HTTP vs autres protocoles

⚡ PBF (Policy Based Forwarding)

Évaluation AVANT la FIB lookup
Basé sur src, dst, app, zone, user
HTTP/HTTPS → tunnel Netskope (indépendant de la route)
RFC1918 → route normale (no-pbf)
Précision chirurgicale dans le steering

Interface ae3.80 — vr_prod

Interface Layer3, Virtual Router vr_prod. Plusieurs IPs secondaires assignées pour les deux Gateways GlobalProtect :

# Interface ae3.80 (agrégation / LACP)
interface ae3.80
  type         Layer3
  virtual-router  vr_prod
  security-zone   Outside
  ip           158.64.24.14/28    # IP principale (GP GW1)
  ip           158.64.24.13/32    # IP secondaire
  ip           158.64.24.9/32     # IP secondaire
  ip           158.64.24.8/32     # IP GP GW2
  ip           158.64.60.0/24     # Plage WAN étendue
  ip           192.103.2.0/24     # Plage legacy

# Tunnels Netskope (interfaces logiques)
interface tunnel.1
  ip           10.161.6.216       # NH Netskope AMS
  comment      Netskope-Amsterdam

interface tunnel.2
  ip           10.178.6.216       # NH Netskope FRA
  comment      Netskope-Frankfurt

Monitoring des tunnels Netskope

# Vérifier l'état des tunnels IPSec
show vpn ike-sa
show vpn ipsec-sa

# Vérifier la table de routage vr_prod
show routing route virtual-router vr_prod

# Vérifier les sessions matchant les règles PBF
show pbf rule statistics

# Vérifier les tunnels GlobalProtect
show global-protect-gateway current-user
show global-protect-gateway statistics

Flux réseau détaillé

Chemin complet du trafic pour un utilisateur en télétravail accédant à un site web via le VPN GlobalProtect.

Scénario : accès à google.com depuis le domicile

Connexion VPN GlobalProtect

Le client GP contacte le Portal Palo Alto (HTTPS/443 vers 158.64.24.14) → authentification → sélection Gateway → tunnel IPSec/SSL établi → IP 10.250.x.x attribuée au poste

↓

Requête DNS (depuis 10.250.x.x)

La requête DNS vers 8.8.8.8 passe par le tunnel GP → arrive sur le Palo Alto → selon les règles : soit via Netskope (si DNS/HTTPS), soit sortie directe. Le Palo voit tout le trafic.

↓

Requête HTTP/HTTPS vers google.com

Paquet : src=10.250.x.x dst=142.250.x.x (google) port=443

↓

Évaluation PBF sur le Palo Alto

Règle no-pbf RFC1918 → ne match pas (142.250.x.x n'est pas RFC1918) → règle NETSKOPE HTTP/HTTPS → match ! → forward vers tunnel.1 (NH: 10.161.6.216)

↓

Encapsulation IPSec vers Netskope AMS

Le paquet est encapsulé dans le tunnel IPSec (tunnel.1) → envoyé au PoP Netskope Amsterdam via Internet. L'IP source vue par Netskope est l'IP publique du Palo (158.64.24.14).

↓

Inspection Netskope

Netskope déchiffre le trafic (TLS inspection si activé), applique les policies CASB/SWG/DLP, log l'accès (utilisateur, URL, catégorie, volume), puis autorise la sortie

↓

Sortie Internet depuis Netskope

Netskope fait un SNAT → l'IP source devient 163.116.240.135 (IP publique Netskope AMS) → requête envoyée à google.com depuis l'AS55256 (Netskope Inc.)

↓

Retour du trafic

Google répond à 163.116.240.135 → Netskope reçoit, désencapsule → re-encapsule dans le tunnel IPSec → retour vers le Palo Alto → délivré au client 10.250.x.x via le tunnel GP

Scénario : accès au LAN interne (192.168.10.x)

10.250.x.x→ paquet src: 10.250.x.x, dst: 192.168.10.1

PBF Check→ règle no-pbf RFC1918 matche (192.168.x.x = RFC1918)

No PBF→ forwarding normal selon la table de routage vr_prod

NAT Palo→ SNAT vers IP publique 158.64.x.x si nécessaire, ou routage interne direct

LAN→ paquet livré sur le réseau interne. Netskope n'est jamais impliqué.

Résultat : le trafic interne ne passe jamais par Netskope. Séparation nette entre trafic Internet (inspecté par Netskope) et trafic interne (géré par le Palo seul).

Résumé visuel des flux

── Utilisateur VPN (10.250.x.x) ──────────────────────────────────

Destination RFC1918  →  No PBF  →  Route normale  →  LAN / DC
                                              ↑ NAT Palo si besoin

Destination Internet
  HTTP/HTTPS          →  PBF NETSKOPE  →  tunnel.1 (AMS)  →  163.116.240.x  →  🌐
                                         ↘  tunnel.2 (FRA)  →  163.116.176.x  →  🌐
                                              ↑ load balancing / failover

  Autres protocoles   →  Route standard  →  Sortie WAN directe ae3.80  →  🌐

Dépannage — Troubleshooting

Commandes Palo Alto utiles

# ══ GlobalProtect ══
show global-protect-gateway current-user
# Liste les utilisateurs VPN connectés

show global-protect-gateway statistics gateway <nom-gw>
# Stats de la gateway (connexions, paquets)

show global-protect-portal current-user
# Utilisateurs authentifiés au portal

# ══ Tunnels IPSec Netskope ══
show vpn ike-sa
# Phase 1 IKE — vérifier que les SA sont up

show vpn ipsec-sa
# Phase 2 IPSec — vérifier les SA actives

show vpn ike-sa gateway <nom-gateway>
# Détail d'un tunnel spécifique

# ══ PBF ══
show pbf rule statistics
# Compteurs de hits par règle PBF — vérifier que les règles NETSKOPE ont des hits

# ══ Routage ══
show routing route virtual-router vr_prod
# Table de routage — vérifier les routes vers 10.161.6.216 et 10.178.6.216

# ══ Sessions ══
show session all filter source 10.250.0.1
# Sessions actives d'un client VPN spécifique

show session id <id>
# Détail d'une session (ingress/egress zone, PBF, NAT)

Diagnostic des tunnels Netskope

# Test de connectivité vers les next-hops Netskope
ping host 10.161.6.216 source tunnel.1
ping host 10.178.6.216 source tunnel.2

# Vérification que les plages Netskope sont routables
test routing fib-lookup virtual-router vr_prod ip 163.116.240.135

# Depuis la console Netskope Admin
# Settings → Security Cloud Platform → Steering Configuration
# → IPSec Tunnels → vérifier status "Connected"

Problèmes fréquents

Utilisateur voit 2 IPs différentes sur "whatismyip"

Cause : Load balancing entre tunnel.1 (AMS) et tunnel.2 (FRA) → IP de sortie alterne entre 163.116.240.135 et 163.116.176.115.

Solution : Normal — c'est le design. Confirmer via show pbf rule statistics que les deux règles ont des hits. Si besoin de forcer un tunnel, modifier la priorité PBF.

Tunnel IPSec Netskope down — trafic web bloqué

Cause : Phase 1 ou Phase 2 IPSec tombée. Le PBF essaie de forwarder vers un NH inaccessible.

Solution : Vérifier show vpn ike-sa. Si les deux tunnels sont down, le trafic web des clients VPN sera bloqué (PBF forward vers NH mort). Ajouter du path monitoring sur les règles PBF pour failback vers la route standard si Netskope est inaccessible.

Trafic interne part vers Netskope par erreur

Cause : La règle no-pbf RFC1918 n'est pas en première position, ou une adresse interne n'est pas dans la liste RFC1918.

Solution : Vérifier l'ordre des règles PBF. La règle no-pbf DOIT être avant les règles NETSKOPE. Ajouter toutes les plages internes (y compris 10.250.x.x des clients GP eux-mêmes si besoin d'exclure le trafic de management).

Client GlobalProtect ne se connecte pas

Cause possible 1 : Port 443 bloqué côté ISP du client. GP peut se rabattre sur UDP/4501.

Cause possible 2 : Certificat du Portal expiré → le client refuse la connexion.

Cause possible 3 : La route de retour vers 10.250.x.x est absente sur le Palo Alto.

Diagnostic : show global-protect-gateway current-user + vérifier les logs GlobalProtect dans Monitor → Logs → GlobalProtect.

Inspection TLS Netskope — erreurs certificat côté client

Cause : Si l'inspection TLS est activée sur Netskope, celui-ci re-signe les certificats avec son propre CA. Si le CA Netskope n'est pas installé sur les postes clients, les navigateurs affichent des erreurs de certificat.

Solution : Déployer le certificat CA Netskope via GPO/MDM sur tous les postes managés. Exclure certaines catégories (banking, health) de l'inspection TLS.

Logs à consulter en priorité

Problème	Logs Palo Alto	Logs Netskope
GP ne connecte pas	Monitor → GlobalProtect	N/A
Tunnel IPSec down	Monitor → System (severity: High)	Settings → Steering → IPSec status
Site web bloqué	Monitor → Traffic + Threat	Skope IT → Events → Application Events
IP inconnue observée	Monitor → Traffic (filter by user/src)	Skope IT → Events → Network Events
DLP déclenché	Monitor → Data Filtering	Skope IT → Events → DLP Events

Flash Cards — SASE / Palo Alto / Netskope

Cliquez sur une carte pour révéler la réponse.

Qu'est-ce que SASE ?

Secure Access Service Edge — Framework Gartner fusionnant SD-WAN et SSE (CASB, SWG, ZTNA, FWaaS) en une plateforme cloud-native. La sécurité suit l'utilisateur.

Différence SSE vs SASE ?

SSE = partie sécurité uniquement (CASB+SWG+ZTNA+DLP). SASE = SSE + SD-WAN. Netskope est un fournisseur SSE. Le SD-WAN peut être Palo Alto ou tiers.

À quoi sert le PBF dans cette architecture ?

Forcer le trafic HTTP/HTTPS Internet des clients VPN (10.250.x.x) vers les tunnels IPSec Netskope — indépendamment de la table de routage. RFC1918 = no-pbf.

Pourquoi 2 tunnels Netskope ?

HA + Load Balancing : tunnel.1 → Amsterdam (163.116.240.135), tunnel.2 → Frankfurt (163.116.176.115). Si un PoP tombe, l'autre prend le relais. L'utilisateur peut voir 2 IPs différentes.

IP de sortie Internet des utilisateurs VPN ?

163.116.240.135 (Netskope AMS) ou 163.116.176.115 (Netskope FRA) — AS55256 Netskope Inc. PAS l'IP publique du Palo Alto (158.64.x.x).

Composants GlobalProtect ?

Portal : auth + distribution config. Gateway : terminaison tunnel + policy. Client : agent sur le poste. Notre archi : 2 Gateways sur ae3.80 (tunnel.100 + tunnel.102).

Pourquoi NAT à la fois sur Palo ET Netskope ?

Palo SNAT : 10.250.x.x → 158.64.x.x pour trafic interne/non-Netskope. Netskope SNAT : IP interne → 163.116.x.x pour sortie Internet. Rôles complémentaires, non redondants.

ASN de Netskope ?

AS55256 — Netskope Inc. Les plages 163.116.240.0/24 (AMS) et 163.116.176.0/24 (FRA) sont annoncées par cet ASN. Vérifiable via bgp.he.net ou RouteViews.

Que fait Netskope sur le trafic HTTP/HTTPS ?

CASB inline (contrôle SaaS), SWG (filtrage web + URL), DLP (prévention fuite données), Threat Protection (malware/sandbox), logging complet des accès utilisateur. Inspection TLS si configurée.

Commande pour vérifier les tunnels IPSec sur Palo Alto ?

show vpn ike-sa (Phase 1) et show vpn ipsec-sa (Phase 2). Pour les stats PBF : show pbf rule statistics.

Modes de steering Netskope ?

Client NPA (agent poste), IPSec tunnel (notre archi — depuis FW), GRE tunnel (sans chiffrement natif), Proxy explicite (PAC file), API CASB (data at rest).

Qu'est-ce que le CASB ?

Cloud Access Security Broker — contrôle et visibilité sur les applications SaaS (M365, Salesforce, Box…). Peut être inline (proxy) ou API (audit des données stockées). Netskope est leader CASB.

Architecture Palo Alto GlobalProtect + Netskope