GET VPN

[parthrawat979]

So, as per cisco's configuration guide: 

The GDOI protocol is protected by an ISAKMP Phase 1 exchange. The GDOI key server and the GDOI group
member must have the same ISAKMP policy. This Phase 1 ISAKMP policy should be strong enough to
protect the GDOI protocol that follows. The GDOI protocol is a four-message exchange that follows the Phase
1 ISAKMP policy. The Phase 1 ISAKMP exchange can occur in main mode or aggressive mode.
The ISAKMP Phase 1 messages and the four GDOI protocol messages are referred to as the GDOI registration,
and the entire exchange that is shown is a unicast exchange between the group member and the key server.

Interestingly I did a packet capture between something weird their are no ISAKMP Messages and I know that all the data is being in the UDP payloads with the port 848 (GDOI), but why it works like this? I assume to see ISAKMP Phase 1 negotiations initially and then GDOI packets would make more sense. I couldn't understand it all like it's just plain data I believe so what kind of encryption is this??

[M02@rt37]

Hello @parthrawat979 

If you are capturing traffic after the initial registration phase or on an intermediate segment, you may only see UDP/848 trafic carrying encrypted payloads !

The phase 1 isakmp process establishes the secure channel and dervices keying material used to protect subsequent gdoi exchanges, after which the 4-message gdoi registration process occurs...

The paylod itself is not plain text even if Wireshark does not decode it properly. 

Also, GetVPN use a Key server and Group members model...where rekeys may later be distributed separately, so depending also on where and when the capture was taken...initial isakmp nego may already have completed befire your capture started.

[parthrawat979]

First of all I've placed the caputre on work just before I apply the crypto map on appropriate interface of the GM.
And if you do look closely you'll find their are 10 messages negotiated, and I believe 6 are of isakmp phase1 and the remaining 4 are the gdoi as shown in the figure below:

now I've the question how can I decode the udp packet on wireshark and make some sense out of it? or do I have to use any other method than wireshark, like I used Strongswan for the decryption of ESP packets.

[M02@rt37]

Mmmm ok... 

The confusing part is that wireshark does not automatically dissect or decrypt GDOI payload content simply because it recognizes udp/848. Once the ISAKMP P1 SA is established, the subsequent GDOI reg messages are protected using keys derived from that exchange, so wireshark only sees encrypted ISAKMP payloads unless you provide the session keys.

Unlike esp decryption with strongswan where keys can be exported, GDOI/GetVPN does not offer a straightforward key export mechanism for wireshark decoding !!!!

You can try enabling full ike debuging...and correlate the spi values and key exchange events with the packet capture.

In wireshark, also ensure udp_848 is manually decoded as GDOI because sometimes it remain as generic UDP. However, even after decoding, payload visibility will still be limited because wireshark understands the protocol structure but cannot decrypt protected contents without session material... 

[parthrawat979]

I may decode is as ISAKMP now and I've got six main mode packets and four quick mode packet here. I've one more question I've decrypted ESP using Strongswan, but I couldn't find any way to decrypt ISAKMP encrypted messages.The logging using charon didn't quite go well for me. How can I decrypt these messages to atleast see the data inside in this gdoi packet capture?? And where are my policies they aren't shown as in normal isakmp is it the reserved2 which I'm seeing in the packet but it says it's only 2 bytes and the next payload is also like 0000??

[M02@rt37]

Those 4 “Quick Mode” packets are actually GDOI registration messages wrapped in isakmp structures, not normal ipsec quick mode exchanges. ISAKMP encrypted payloads can not be easily decrypted like esp unless you have the exact ike session keys, and GetVPN does not provide a simple key export for wireshark... 

The missing policies are likely hidden inside the encrypted payload after main mode completes. Fields you see are usually just wreshark showing raw or unknown encrypted content...

[parthrawat979]

But ISAKMP should carry the policies in the main mode right?? And the first packet of ISAKMP shows DOI: GDOI and the reserved2 thing. The SA payload shows a size of 60 bytes in the first packet but it only got the value of 10-12 bytes the remaining part can't be seen at all which contains the proposal's of policies.

[M02@rt37]

@parthrawat979

Normaly main mode carries ISAKMP policy proposals in the sa payload.

But with GDOI, the DOI changes to GDOI and wireshark often struggle to fully decode those payloads. So the missing bytes are likely there, but wireshark is not parsing the GDOI proposal structure correctly.

Reserved2 is usually a dissector limitation...not actual protocol data.

[parthrawat979]

So, is it possible to see those fields?? Apart from wireshark since wireshark can't show those.