Step 1: enable IPSec Logging (System → Logging → IPSec to Memory) Step 2: Set your IPSec-Tunnel to use 3DES encryption (only 3DES can be decrypted by Wireshark) Step 3: Configure the Packet Sniffer to capture “UDP 500”, Output-File: “isakmp.pcap” Step 4: Start Packet-Sniffer, Start establishing IPSec-Tunnel, Stop Sniffer Step 5: Copy Mikrotik-Log to a file: /log print file=log Step 6: Download “isakmp.pcap” and “log.txt” from Files Step 7: Open log.txt with proper Text-Editor (e.g. Notepad++)
Now the tricky part, find the Decryption Variables which we need for Wireshark Step 8: Search for COOKIE (here my example)
15:03:36 ipsec sent phase1 packet 192.168.0.xx[500]<=>192.168.0.xx[500] 7c6139ded9ca7187:6992a9097bf7082a Step 9: Search for Encryption Key (here my example)
15:03:36 ipsec,debug final encryption key computed:
15:03:36 ipsec,debug fc9c635a a7a316d3 7442463e d2e581ea 1263b66b 94ada5ec
Step 10: Open your Dump file “isakmp.pcap” in Wireshark (I used the latest version 2.2.3) Step 11: Right-Click on an ISAKMP-Packet → Protocol Settings → IKEv1 Decryption Table Step 12: Click on [+] and add the Cookie and Encryption key without blanks inbetween, trailing or leading
Why did I do all of this? My Android tablet using IPSec-Xauth-PSK can not authenticate:
15:03:36 ipsec,debug Attribute XAUTH_USER_NAME len 4
15:03:36 ipsec,debug Attribute XAUTH_USER_PASSWORD len 5
15:03:36 ipsec,info Xauth login failed for user: test
The root-cause is known: my password is 4 digits long but android sends a 5 digit password → for a fix, see http://forum.mikrotik.com/viewtopic.php?p=576563#p576563
There is an alternative way to visualise ISAKMP messages in Wireshark which handles any encryption algorithm because it uses Mikrotik’s own decryption.
Instead of copying the decryption key from Mikrotik’s log, you copy the decrypted received packet bytes, reformat them to form up a hexdump text, and import that hexdump to Wireshark. But before doing that, you have to change the LSB of the byte at offset 19 (0x13) to 0 to indicate that the packet contents is not encrypted.
Example:
17:16:08 ipsec,debug decrypted.
17:16:08 ipsec,debug cf799370 3348f607 b93a5364 dff8e5c1 08102001 d07af856 000000bc 01000018
17:16:08 ipsec,debug bbdc223a 45e440a6 08cdc9f9 f76330d8 7dd34ee3 0a000034 00000001 00000001
17:16:08 ipsec,debug 00000028 01030401 051362b2 0000001c 030c0000 80010001 80020708 80040004
17:16:08 ipsec,debug 80060100 80050002 0500001c d63a6d7e 34482207 4854d91a cd3939fc 5b8f2cee
17:16:08 ipsec,debug 069bbca6 0500000c 011106a5 c0a805ad 1500000c 011106a5 c0a80a58 1500000c
17:16:08 ipsec,debug 01001194 0a000005 0000000c 01001194 c0a80a58 61b34e5d 7b4c7d07converts into
0000 cf 79 93 70 33 48 f6 07 b9 3a 53 64 df f8 e5 c1 08 10 20 01 d0 7a f8 56 00 00 00 bc 01 00 00 18
0020 bb dc 22 3a 45 e4 40 a6 08 cd c9 f9 f7 63 30 d8 7d d3 4e e3 0a 00 00 34 00 00 00 01 00 00 00 01
0040 00 00 00 28 01 03 04 01 05 13 62 b2 00 00 00 1c 03 0c 00 00 80 01 00 01 80 02 07 08 80 04 00 04
0060 80 06 01 00 80 05 00 02 05 00 00 1c d6 3a 6d 7e 34 48 22 07 48 54 d9 1a cd 39 39 fc 5b 8f 2c ee
0080 06 9b bc a6 05 00 00 0c 01 11 06 a5 c0 a8 05 ad 15 00 00 0c 01 11 06 a5 c0 a8 0a 58 15 00 00 0c
00a0 01 00 11 94 0a 00 00 05 00 00 00 0c 01 00 11 94 c0 a8 0a 58 61 b3 4e 5d 7b 4c 7d 07
Byte at offset 19 has a value of 01, so you change it to 00:
0000 cf 79 93 70 33 48 f6 07 b9 3a 53 64 df f8 e5 c1 08 10 20 01 d0 7a f8 56 00 00 00 bc 01 00 00 18
v
0000 cf 79 93 70 33 48 f6 07 b9 3a 53 64 df f8 e5 c1 08 10 20 00 d0 7a f8 56 00 00 00 bc 01 00 00 18
…Then, you save the result to a file. A space MUST follow the last hex digit on the last line of the hex dump.
As the last step you use the “Import from Hex Dump” functionality of Wireshark to import the file, adding an UDP “dummy header” with source port 500 or 4500 as appropriate.
The above works for IKEv1; for IKEv2, the procedure is slightly more complex as the log only contains part of the received packet in decrypted form, so it is necessary to fiddle with the data more. On the other hand, in contrary to the IKEv1 case, the log contains also the sent packets before encryption, which is often helpful (and these don’t require any fiddling at all, just a conversion to hex dump without change of a single bit).
19:29:43 ipsec,debug ===== received 80 bytes from [remote-port] to [4500]
19:29:43 ipsec,debug,packet 97b252ac 78eebb53 f5a387d1 04d55f3e 2e202508 00000002 00000050 29000034
19:29:43 ipsec,debug,packet 922d55c3 d6a2c3d8 26648d96 7b9c6d2b 0bb43ed3 39b92ba2 d492fb0a 0f3c76d4
19:29:43 ipsec,debug,packet eafe86b9 a830330b 021f835a 73993273
19:29:43 ipsec ike2 request, exchange: INFORMATIONAL:2 [remote-port]
19:29:43 ipsec payload seen: ENC
19:29:43 ipsec processing payload: ENC
19:29:43 ipsec,debug => iv (size 0x10)
19:29:43 ipsec,debug 922d55c3 d6a2c3d8 26648d96 7b9c6d2b
19:29:43 ipsec,debug decrypted
19:29:43 ipsec,debug,packet => decrypted packet (size 0x8)
19:29:43 ipsec,debug,packet 00000008 00000018
19:29:43 ipsec payload seen: NOTIFY
To create the hex dump for Wireshark import, we have to
take the first 28 bytes of the encrypted packet dump (the whole first line except the last 32-bit word)
append to it the decrypted packet contents
adjust the total ISAKMP data size value, i.e. the word at offset 26 (0x1a), to the resulting size (i.e. the size of the decrypted portion + 28)
set the next-payload type at offset 16 (0x10) to the proper one, as suggested by the first “payload seen” line following the decrypted packet - in this case, NOTIFY (41/0x29). This IANA table is helpful here.
So from
19:29:43 ipsec,debug,packet 97b252ac 78eebb53 f5a387d1 04d55f3e 2e202508 00000002 00000050 29000034
…
19:29:43 ipsec,debug,packet 00000008 00000018
19:29:43 ipsec payload seen: NOTIFY
we first create
0000 97 b2 52 ac 78 ee bb 53 f5 a3 87 d1 04 d5 5f 3e 2e 20 25 08 00 00 00 02 00 00 00 50
001c 00 00 00 08 00 00 00 18
and then modify the first line:
0000 97 b2 52 ac 78 ee bb 53 f5 a3 87 d1 04 d5 5f 3e 2e 20 25 08 00 00 00 02 00 00 00 50
vv vv vv
0000 97 b2 52 ac 78 ee bb 53 f5 a3 87 d1 04 d5 5f 3e 29 20 25 08 00 00 00 02 00 00 00 24