In this blog post, we're going to walk through NAT Traversal and the different considerations to think about when a firewall is in the path of the VPN peers.
I'm going to use the same configuration from the previous site-to-site IOS VPN blog post but with one difference: I've placed an ASA in the path with PAT configured on it. This topology is displayed below.
When you first attempt ISAKMP it will fail. The reason becomes clear in the debug output from debug crypto isakmp. In this case, the previously configured ISAKMP peer was the pre-NAT IP address so when the Main Mode messages came from the NAT IP, the peer didn't recognize it.
In order to fix this, I'm going to change the ISAKMP and crypto map peer:
crypto isakmp key cisco123 address 2.2.2.2 crypto map CMAP 10 ipsec-isakmp no set peer 1.1.1.1 set peer 2.2.2.2
Now let's attempt again to establish the IPSec VPN and see what happens.
As we look at the debug crypto isakmp output, we should first see the NAT is detected during MM#3 and MM#4 by the responder:
The responder will reply to the next Main Mode message encapsulated in a UDP packet source and destination port 4500 so PAT will have stateful information to install in it's PAT binding table once Phase 2 begins
At this point, the initiator will see the message encapsulated in UDP and start replying with it's own packets encapsulated in UDP 4500 which you can see from the debug output below from the initiator.
After this, Phase 1 and Phase 2 should complete and communication should be allowed through.
From the PC, you should also see the ping traffic complete with the exception of the first ping as the IPSec VPN tunnel is being established on the routers.
Great! It looks like everything works perfectly when the initiator is the peer from the inside of the PAT device. Let's issue the clear crypto session command and try something different. This time I'm going to initiate the traffic from the site outside of the firewall. I'm going to have the PC on the 192.168.2.0/24 LAN attempt to ping the other PC.
This time it will fail as you can see below.
Let's take a look at the initiator router's debug output:
It looks like the initiator never makes it past the first Main Mode message. If you look at the debug output on the responder, there won't be anything showing up at all.
The reason for this is that you're trying to initiate traffic from a lower security interface to a higher interface. By default, the ASA should be doing it's job and blocking any traffic from the lower security interface. You need two things in order to get the Main Mode messages from the peer on the outside to the peer on the inside:
1. NAT Statements - The ASA needs to know that the traffic coming to it's outside IP address should be mapped to the inside router's IP address. This can be done by creating a NAT statement with specific port mapping on the outside interface or a NAT statement with a separate IP address instead of the interface's IP.
2. ACL - In order to not be blocked, an ACL needs to be configured to allow UDP 500 and 4500 on the outside interface from one peer ot the other.
Note: If you're using post-8.3 ASA IOS code (which you will have to for the CCIE lab but I know there's a lot of folks out there with old code), be sure to write your ACLs and NAT statements with the real IP.
Create the NAT statements on the ASA which allow UDP 4500 and 500 through to the outside interface of the router:
object network R1 host 1.1.1.1 object service UDP_4500 service udp source eq 4500 object service UDP_500 service udp source eq 500 nat (inside,outside) 1 source static R1 interface service UDP_500 UDP_500 nat (inside,outside) 1 source static R1 interface service UDP_4500 UDP_4500
The NAT statement isn't enough to allow the VPN to come up. Since the traffic is still traveling from the interface with the lower security level to the higher security level, we need to configure an access list to allow the traffic from our peers through on the ports we want. The configuration for the ACL I used is:
access-list OUT_IN extended permit udp host 2.2.2.1 eq isakmp host 1.1.1.1 eq isakmp access-list OUT_IN extended permit udp host 2.2.2.1 eq 4500 host 1.1.1.1 eq 4500
Then apply the ACL to the outside interface:
access-group OUT_IN in interface outside
Now let's try to initiate the traffic from the outside peer to the inside peer again and see what happens. This time the ping from the PC should go through.
On the debugs from the routers, it'll show Phase 2 complete.
With that, I'm going to wrap up this blog post! Thank you for reading!