How to Decrypt IKE and ESP Packets on a Palo Alto Networks Device
Resolution
Overview
When ipsec tunnels terminate on a Palo Alto Networks firewall, it is possible to decrypt the traffic using the keys registered under ikemg.log. This can be very useful for troubleshooting ike, and performance issues with ipsec tunnels such as packet-loss and out-of-order packets.
Details
On this article, we will illustrate how to decrypt ikev1 on main mode and ESP packet using the following topology. The same steps can be used with ikev2.
By default, the debugging level of ikemgr is normal. To log the negotiated authentication and encryption keys, we must increase the debugging level to dump.
admin@FW1> debug ike global show
sw.ikedaemon.debug.global: normal
admin@FW1> debug ike global on dump
admin@FW1> debug ike global show
sw.ikedaemon.debug.global: dump
Packets can be captured anywhere between FW1 and FW2. On our test setup, we will take packet captures on FW1 following this guide https://live.paloaltonetworks.com/t5/Learning-Articles/How-to-Run-a-Packet-Capture/ta-p/62390.
To capture clear and encrypted data between User1 and User2 we are going to use the following filters.
admin@FW1> debug dataplane packet-diag show setting
--------------------------------------------------------------------------------
Packet diagnosis setting:
--------------------------------------------------------------------------------
Packet filter
Enabled: yes
Match pre-parsed packet: no
Index 1: 192.168.112.104[0]->192.168.125.110[0], proto 0
ingress-interface any, egress-interface any, exclude non-IP
ingress-interface any, egress-interface any, exclude non-IP
Index 2: 10.193.121.91[0]->10.193.121.93[0], proto 0
ingress-interface any, egress-interface any, exclude non-IP
ingress-interface any, egress-interface any, exclude non-IP
--------------------------------------------------------------------------------
Logging
Enabled: no
Log-throttle: no
Sync-log-by-ticks: yes
Features:
Counters:
--------------------------------------------------------------------------------
Packet capture
Enabled: yes
Snaplen: 0
Stage receive : file rx
Captured: packets - 0 bytes - 0
Maximum: packets - 0 bytes - 0
Stage transmit : file tx
Captured: packets - 1 bytes - 0
Maximum: packets - 0 bytes - 0
Stage drop : file dr
Captured: packets - 0 bytes - 0
Maximum: packets - 0 bytes - 0
At this point, we need to bounce the ipsec tunnel to start a new negotiation process and log the ipsec phase1 and phase2 keys.
admin@FW1> clear vpn ike-sa gateway TO-FW2
admin@FW1> clear vpn ipsec-sa tunnel To-FW2
Then generate Traffic between User1 and User2 and make sure that the tunnel is up.
admin@FW1> show vpn ike-sa gateway TO-FW2
IKEv1 phase-1 SAs
GwID/client IP Peer-Address Gateway Name Role Mode Algorithm Established Expiration V ST Xt P
hase2
-------------- ------------ ------------ ---- ---- --------- ----------- ---------- - -- -- -
-----
1 10.193.121.93 TO-FW2 Init Main PSK/ DH2/A128/SHA1 Apr.08 21:57:04 Apr.08 22:03:04 v1 12 4 1
Show IKEv1 IKE SA: Total 2 gateways found. 1 ike sa found.
IKEv1 phase-2 SAs
GwID/client IP Peer-Address Gateway Name Role Algorithm SPI(in) SPI(out) MsgID ST Xt
-------------- ------------ ------------ ---- --------- ------- -------- ----- -- --
1 10.193.121.93 TO-FW2 Init ESP/ DH5/tunl/SHA2 B57366C2 B82D7CDE 547B1BD5 9 1
Show IKEv1 phase2 SA: Total 2 gateways found. 1 ike sa found.
Decrypt ikev1 on main mode.
With ikev1, the identification and quick mode messages are encrypted. Sometimes it is necessary to decrypt them to verify which parameters were exchanged between the two peer.
Here is an example of an encrypted identification message.
To decrypt ikev1 messages, we need two pieces of information.
- Initiator’s cookie that corresponds to the Initiator SPI on the packet capture. 294ff0e604e73f31
- Encryption key that can be found on the ikemgr.log: Search for “cookie:294ff0e604e73f31” and then scroll through the negotiation messages untill you find the final computed encryption key.
2017-04-08 21:57:04 [DEBUG]: oakley.c:3157:oakley_compute_enckey(): final encryption key computed:
2017-04-08 21:57:04 [DEBUG]: oakley.c:3158:oakley_compute_enckey():
793f8697 cc0e8cdb 5851496c 0acff14c
Next, go to Wireshark > Edit > Preferences > Protocols > ISAKMP > IKEv1 Decryption Table and enter the Initiator’s COOKIE and Encryption key:
And here is the decrypted identification message:
Decrypt ESP packets.
Decrypting ESP packets follows the same principle as ike, but require more parameters.
- Protocol: IPv4
- Src IP: The source IP of the ESP packets you want to decrypt. For the example above 10.193.121.91
- Dst IP: The destination IP of the ESP packets you want to decrypt. For the example above 10.193.121.93
- ESP SPI: You can find it on the packet capture under Encapsulation Security Payload. In our example, it is 0xb82d7cde
- Encryption and Authentication Algorithm: They are part of the output of ‘>show vpn flow ‘ command.
admin@FW1> show vpn flow name To-FW2 | match algorithm
auth algorithm: SHA256
enc algorithm: AES128
- Encryption and Authentication Key which can be found on the ikemgr.log:
21.93[500]/0, satype=141 (ESP), spi=, wsize=4, authtype=41 (SHA256), enctype=15 (AES128), saflags=0x0, samode=137 (tunl), reqi
d=0, lifetime hard time 180, bytes 0, lifetime soft time 146, bytes 0, enckey len=16 [3d6991e6a0f888d240c8d539a54676a7], authkey len=32
[bbac69f722297906c11d7d9038248ba3b509519a0e1e37bb0652752130c8324c]
Next, go to Wireshark > Edit > Preferences > Protocols > ESP Decryption and select “Attempt to detect/decode encrypted ESP payloads”:
Then edit the ESP SAs.
After that you will see the ESP packets decrypted.