IKE Challenges

A few month ago I published many Layer 2/3 challenges on my blog. Beside the happy feedback I got some remarks that the challenges were to easy at all because you only needed the display filter at Wireshark while no deep protocol knowledge.

Ok, “challenge excepted” ;) here I have some more protocol related challenges for you: With this post I am publishing a pcap which has four site-to-site IPsec VPN connections inside. On the first half of the pcap all four of them are wrongly configured, hence, not working. –> What are the reasons for that? <–

Scenario

Consider the following scenario: You are the network administrator of four new remote offices and should configure VPN connections from each site to the headquarter. You agreed with the firewall admin from the headquarter about all VPN settings. However, none of your four VPN connections is working while you have configured everything correctly. Since the firewall admin of the headquarter is not willing to give you access to his firewall, your only chance in proving the errors on his side is to analyze a packet capture taken on the WAN interfaces of your routers.

Challenges

At first download the following pcap and open it with Wireshark for the analysis:

The file shows only ISAKMP, ESP and ICMP packets. For the first half of the capture (packets no. 63-250) I (the headquarter firewall admin) misconfigured each VPN with a wrong value in order to have no single VPN working! These are:

  • wrong phase 1 proposals
  • wrong peer ID
  • wrong proxy-ID
  • wrong pre-shared key

Your job: Which of the following four peers had which error configured?!?

In the second half of the capture (packets no. 475-570, followed by many ESP packets) everything is working fine since I corrected the misconfigured settings. Hence you can try to compare the working and not-working sessions.

Please use the comment section below to paste your answers as well as a description how you solved it. The names and IPs are as follows. You can use it as a template for your answers:

I’ll publish the solutions in a couple of weeks here on my blog. Have fun. ;)

Setup

My setup consisted of four AVM FRITZ!Box home routers that established a VPN connection via IPsec over legacy IP (IPv4) to a Palo Alto Networks firewall. While the firewall had a static IPv4 address the four routers had dynamic ones. Therefore all VPNs were in the aggressive mode and the firewall was only responder (passive) since all home routers initiated the VPN connections. Note that all four errors were configured on the firewall while the routers had the correct settings all over the trace.

(More Info: Test Procedure)

This was my test sequence, just in case you’re interested:

  1. I deactivated all VPNs on the four home routers
  2. committed the falsified config on the Palo Alto firewall
  3. started the capture on a mirror port on the wan/untrust interface with sudo tcpdump -i eth1 -w IKE-Challenges.pcap 'host 93.220.202.100 or host 79.197.51.33 or host 95.116.124.205 or host 178.4.19.82'
  4. started pinging all remote private IPv4 addresses (through the VPN tunnel) from behind the firewall
  5. activated all VPNs on the home routers
  6. waited a few moments
  7. deactivated all VPNs on the home routers
  8. committed corrected config on the Palo Alto firewall
  9. activated all VPNs on the home routers again
  10. waited a few moments
  11. stopped the capture

That is: Only in the second half of the capture you can see some ESP packets (from working VPN connections), while the first half shows only ISAKMP packets (trying to establish a VPN).

Featured image “Checkmate” by John Vetterli is licensed under CC BY-SA 2.0.

2 thoughts on “IKE Challenges

  1. main firewall: 80.154.108.228
    router 1 “darm”: 93.220.202.100: wrong Ph1 proposals (?), silent discard
    router 2 “fdorf”: 79.197.51.33: wrong pre-shared key
    router 3 “fdorf-k”: 95.116.124.205: wrong Proxy-ID
    router 4 “fdorf-w”: 178.4.19.82: wrong peer ID (?), silent discard

    The task is very difficult for me, I’ve not found a way to spot the difference between 93.220.202.100 and 178.4.19.82. Both attepmts were silently discarded and the only difference they have is FQDN, but I don’t know which FQDN was specified on server-side.

Leave a Reply

Your email address will not be published. Required fields are marked *