Comme expliqué dans le document https://Live.paloaltonetworks.com/docs/doc-5819, les numéros de port pour la création de session IPSec sont dérivés des valeurs SPI que les homologues IPSec distants échangent pendant la phase 2 d'Ike de l'établissement de tunnels. Mais cette méthode peut être appliquée uniquement dans le cas où l'un des homologues IPSec est le pare-feu lui-même, ou en d'autres termes, uniquement si le tunnel IPSec est terminé sur le pare-feu.
Dans le cas du trafic IPSec de passage, où le pare-feu de Palo Alto Networks n'est qu'un périphérique intermédiaire entre deux homologues IPSec, il est pratiquement impossible de créer une session basée sur des valeurs SPI négociées, car la phase 2 d'IKE est cryptée et son contenu est pas visible au pare-feu.
Étant donné que les valeurs SPI ne peuvent pas être vues à l'avance, pour le trafic de transit IPSec, le pare-feu de Palo Alto Networks crée une session à l'aide de la valeur générique 20033 pour le port source et de destination. Dans l'exemple ci-dessous, vous pouvez voir que les ports source et de destination des flux C2S et S2C reçoivent la même valeur, 20033:
admin @ VM-300 > Show session ID 791
session 791
flux C2S:
source: 192.168.0.11 [Trust]
DST: 129.187.7.11
proto: 50
sport: 20033 dport: 20033
État: type actif: Flow
src utilisateur: Unknown
DST utilisation r: Unknown
S2C Flow:
source: 129.187.7.11 [méfiance]
DST: 192.168.0.11
proto: 50
sport: 20033 dport: 20033
État: actif type: Flow
src utilisateur: inconnu
DST utilisateur: inconnu heure de
début: Thu Juin 10 11:58: 59 2015 timeout: 3600 sec temps de vivre: 3142 sec nombre total d'octets (C2S): 1080 nombre total d'octets (S2C): 1014 layer7 nombre de paquets (C2S): 8 layer7 nombre de paquets (S2C): 5 VSys: vsys1 application: IPSec-ESP règle: any-any session à consigner à la fin: vraie session en session Agere: true session mise à jour par ha Peer: false layer7 Processing: achèvement du filtrage d'URL activé: true URL Category: Any session via syn-cookies: false session terminé sur l'hôte: false session traverse tunnel: false captive Portal session: false ingresse interface: ethernet1/2 sortie interface: ethernet1/1 session règle de QoS: N/a (classe 4) Tracker stage l7proc: CTD app n'a pas de décodeur < C46 > end-Reason: inconnu
Sur les séries PA-7000 et PA-5200, en raison d'une différence architecturale, nous utilisons une technique différente pour la création de session de trafic passe-à-travers IPSec. Sur ces plates-formes, les ports de session sont de nouveau dérivés basés sur les valeurs SPI, comme décrit dans https://Live.paloaltonetworks.com/T5/Learning-Articles/What-do-the-Port-Numbers-in-an-IPSec-ESP-sess... , mais étant donné que les valeurs SPI ne sont pas connues à l'avance, le pare-feu crée une session car le trafic ESP réel arrive sur le pare-feu. Avoir chaque flux (client2server, server2client) d'un tunnel IPSec unique à l'aide d'une valeur SPI unique implique que le pare-feu crée deux sessions IPSec indépendantes pour un tunnel IPSec, un par direction. Cela signifie que les stratégies de sécurité doivent être configurées pour autoriser le trafic ESP de transmission dans les deux directions sur les plates-formes PA-7000 et PA-5200.