Some time ago I published a pcap file with some challenges – this time four falsified configured IPsec VPN connections. If you have not solved it by now you should first download the pcap file and should give it a try.
Remember the scenario: You need to prove that the wrong VPN settings are not on your side (the four routers) but on the headquarters firewall side. Not an easy job. Now here are the solutions:
Sorry, but to be honest you could not fully succeed these challenges by only looking at the trace file. ;) In some misconfigurations, the firewall is not responding at all. Hence in some cases, you can only guess which error was configured on which VPN peer. (A quite realistic scenario in my daily business …)
For example, the “wrong peer ID” and “wrong phase 1 proposals” cannot be distinguished within the trace since in both cases the firewall does not reply at all. Both settings are related to IKE phase 1. They can only be solved by looking at the logs of the main firewall.
At least the other two cases can be solved: “wrong pre-shared key” leads to answers from the firewall but never succeeds in a complete VPN connection. Every few seconds a new connection is started but never continues. Finally, “wrong proxy-IDs” succeeds completely with phase 1 but stucks in phase 2 (quick mode) since the proxy-IDs are wrong. The VPN is deleted and starts again.
Here we go with some more details from the trace file as well as the firewall logs:
The mere results are as follows:
router 1 "darm": 220.127.116.11: wrong peer ID
router 2 "fdorf": 18.104.22.168: wrong pre-shared key
router 3 "fdorf-k": 22.214.171.124: wrong proxy-IDs
router 4 "fdorf-w": 126.96.36.199: wrong phase 1 proposals
Lost in Translation
Short summary: If you are in trouble with VPN connections you can’t solve them by just capturing at the WAN interface! This should be the primary finding of these challenges. You must look at VPN logs of the responder to solve any IPsec related issues.