In the last article, we configured the site-to-site VPN tunnel between the ASA and the Cisco router to use aggressive mode. Our network diagram is shown below.
We found that the tunnel came up when initiated by the router but did not come up when initiated by the ASA. In this article, we will first look at the debug output for the aggressive mode of IKE phase 1 and then fix the issue we encountered.
Remember, in the last article that we said that aggressive mode contains three messages in three exchanges. When using pre-shared keys for authentication, the exchanges can be represented diagrammatically as shown below:
Let’s go to the terminal. I will initiate the tunnel from the host behind the router (that’s the only way in which it is working currently), while also debugging crypto messages on the ASA. To enable us see what happens in the first packet, we will debug at a level of 255 and then go back to level 9, as we did in previous articles.
The ASA (responder) first receives a message from the router (initiator) in the format: HDR, SA, KE, Ni, IDii, as shown below:
Let’s look at this packet in detail:
As you can see, the “exchange type” is aggressive mode and, similar to its main mode counterpart, all the transforms from the initiator are also contained in this first packet (two transforms in our case).
The other interesting part of this packet is the identification payload shown below:
Remember that with main mode, the identities of the peers are protected and are only sent in the third and fourth packets; however, with aggressive mode, the initiator sends its ID from the start. This first packet is not encrypted, so anyone sniffing the wire can know the identities of the peers communicating. This is why aggressive mode is less secure than main mode.
As you can see from the above, the router identifies itself using its FQDN, just the way we configured it. Now we can continue viewing our debug output at a lower level.
The ASA processes the packet and, as you will notice from the output above, the ASA, using the FQDN ID it received from the router, was able to match the connection to a tunnel group named with the FQDN of the router. It also checks for an acceptable transform (ISAKMP policy) from the initiator and finds a matching one.
At this stage, the ASA is ready to send the second packet in the Aggressive mode exchange.
To complete the exchange (and in effect IKE phase 1), the ASA receives the third packet from the router. This packet also contains NAT discovery payloads, which we will discuss in another article.
So, as we have seen, aggressive mode completes its exchange in fewer messages than main mode and also, since the initiator’s identity is sent in the first packet, we have more options for matching tunnel groups when using PSK authentication.
Resolving the unidirectional initiation of the VPN Tunnel
Now we have come to a troubleshooting section where we will resolve the issue where the ASA cannot initiate the tunnel. First, we confirm that this issue still persists. I will begin by clearing the SAs on both devices. Then I’ll ping from the host behind the ASA.
The ping fails and when we check the SAs on the ASA, we find that there are none.
Since we are already using debug commands, the best way to resolve this issue is to view the debugs.
(Note: Use debugging wisely, as it may have serious performance issues especially on a production network).
I’ll debug on the ASA and initiate the ping again.
The debugs on the ASA are as shown below:
The first line shows that the ASA is the initiator. It constructs a message to send to the router and then it gets a reply back. If you look at the first packet sent, you will see that it does not contain the “ID” field. This should tell you that the ASA initiated IKE Phase 1 main mode. Another thing that points to the fact that main mode is used is there are four back-and-forth messages above; aggressive mode has only three messages.
Continuing with the debug, we have the following, which shows us an error:
By now I suppose you have figured out the error. The ASA initiated main mode and the only tunnel group we have configured is one that has a non-IP address name. Since we are using PSK authentication, this will not work. So, we have to make sure that the ASA initiates aggressive mode. On the ASA, we can control what IKE Phase 1 mode is initiated under the crypto map configuration, as shown below:
I will set it to aggressive mode and then we will try to ping again, still leaving on the debug.
The ASA initiates the tunnel and, as we can see from the output below, this is aggressive mode because the ID field is contained in the packet.
The ASA receives a reply from the router and processes that packet. However, notice what happens below:
The ASA has a tunnel group called “ASA-RTR.example.com” but the router is sending its ID as “10.0.0.2.” This causes the ASA to abort the exchange and start over again; the third message to complete the aggressive mode exchange is never sent.
The final problem actually lies in the router’s configuration. Looking at the ISAKMP profile that we configured on the router, we can see that it is incomplete.
Because we have not specified a match identity in the profile, when the ASA connection gets to the router, the router will not be able to match that profile to the connection. Since the profile is where we specified that the router should respond with its FQDN, if it is not matched, the router will respond with its default ID i.e. IP address.
Let’s edit that configuration by matching the identity of the ASA:
Now when we ping again from the host behind the ASA, see what happens:
It’s a success! If we take a look at the SA on the ASA, we see that aggressive mode is being used and that the ASA is the initiator.
Just to make sure we did not create another issue, let’s check that we can still initiate the VPN tunnel from the router’s side. (If you are doing this along with me, remember to first clear your SAs.)
Great! We can now initiate aggressive mode IKE phase 1 from both sides of the tunnel.
This brings us to the end of this article, in which we have considered the aggressive mode of IKE phase 1 in detail using the debug output. We have seen the three messages that make up the aggressive mode exchange. Also, we fixed the issue of the ASA not being able to initiate the VPN tunnel by setting the phase 1 mode to “aggressive” on the crypto map configuration and also adding the match identity statement under the ISAKMP profile configured on the router.
I should also note at this point that, according to the RFC, main mode MUST be implemented, while aggressive mode SHOULD be implemented. Therefore, main mode is required, while aggressive mode is recommended.
In the next article, we will take a look at NAT discovery. I hope you have found this article insightful and I look forward to presenting the next one in the series.
Reference and helpful resource:
RFC 2409: The Internet Key Exchange (IKE): http://tools.ietf.org/html/rfc2409
Cisco IOS IPsec ISAKMP Profile Overview: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6635/prod_white_paper0900aecd8034bd59.html
Cisco ASA 5500 Series Configuration Guide using the CLI, 8.4 and 8.6: http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/asa_84_cli_config.html
BCP 14: Key words for use in RFCs to Indicate Requirement Levels: http://tools.ietf.org/html/bcp14