As explained in the document https://live.paloaltonetworks.com/docs/DOC-5819, port numbers for IPSec session creation are derived from SPI values that remote IPSec peers exchange during IKE phase 2 of tunnel establishment. But this method can be applied only in case one of IPSec peers is the firewall itself, or in other words, only if the IPSec tunnel is terminated on the firewall.
In the case of pass-through IPSec traffic, where the Palo Alto Networks firewall is just an intermediate device between two IPSec peers, it is practically impossible to create a session based on negotiated SPI values, since IKE phase 2 is encrypted and its content is not visible to the firewall.
Since SPI values can’t be seen in advance, for IPSec pass-through traffic, the Palo Alto Networks firewall creates a session by using generic value 20033 for both source and destination port. In the example below, you can see that source and destination ports of both c2s and s2c flows are given the same value, 20033:
admin@vm-300> show session id 791
Session 791
c2s flow:
source: 192.168.0.11 [trust]
dst: 129.187.7.11
proto: 50
sport: 20033 dport: 20033
state: ACTIVE type: FLOW
src user: unknown
dst user: unknown
s2c flow:
source: 129.187.7.11 [untrust]
dst: 192.168.0.11
proto: 50
sport: 20033 dport: 20033
state: ACTIVE type: FLOW
src user: unknown
dst user: unknown
start time : Thu June 10 11:58:59 2015
timeout : 3600 sec
time to live : 3142 sec
total byte count(c2s) : 1080
total byte count(s2c) : 1014
layer7 packet count(c2s) : 8
layer7 packet count(s2c) : 5
vsys : vsys1
application : ipsec-esp
rule : any-any
session to be logged at end : True
session in session ager : True
session updated by HA peer : False
layer7 processing : completed
URL filtering enabled : True
URL category : any
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : False
captive portal session : False
ingress interface : ethernet1/2
egress interface : ethernet1/1
session QoS rule : N/A (class 4)
tracker stage l7proc : ctd app has no decoder
end-reason : unknown
On PA-7000, PA-5200 and PA-3200 series, due to an architectural difference, we use a different technique for session creation of IPSec pass-through traffic. On these platforms session ports are again derived based on SPI values, as described in https://live.paloaltonetworks.com/t5/Learning-Articles/What-do-the-Port-Numbers-in-an-IPSEC-ESP-Sess..., but since SPI values are not known in advance firewall creates session as real ESP traffic arrives on the firewall. Having each flow (client2server, server2client) of a single IPSec tunnel using a unique SPI value implies that firewall creates two independent IPSec session for one IPSec tunnel, one per each direction. This means security policies must be configured to allow pass-through ESP traffic in both directions on PA-7000, PA-5200 and PA-3200 series platforms.