In this Article, we will be breaking down the right questions to ask when configuring a VPN and how to configure a Site to Site on the ASA.
ASA Version
The configuration of the Site to Site will be presented in different variations at the end of this Article. This is for those using either 7.x through 9.x code of the ASA as things are different between the code versions. I will start with 9 (8.3+) code since this should be the version most are running today and I will follow that up with 7.x-8.2. The Site to Site configuration between these code versions vary so I will present the same configuration in all variations between the code versions.
With all VPNs, we need to gather some information before we get started. Always ask the following as they are crucial to getting the VPNs configured correctly the first time. To jump straight to configuration, click here.
Is the remote side requesting Route Based or Policy Based VPNs?
This is helpful to understand first and foremost your limitations. Until 9.7+, the ASA was not capable of performing a true Route Based VPN. The ASA was only capable of performing Policy Based VPNs but there is always ways to kind of get around those limitations but we will cover that in another Article. For now, if the answer is Policy Based, move on to the next question.
What is the Peer IP?
We need to know the IP of the other VPN Concentrator at the other end. It is also helpful to know if this device is behind a NAT device. That means the devices IP address would actually be a Private IP and would have to be NAT’d to reach your ASA. If this is the case, issues could arise based on the Router settings in front of the device and how the device sends its Identity to your ASA. In most cases, you will be creating the Tunnel Group based on their Public IP so it is good to make sure that this is the Identity (IP) coming from their device to build the tunnel. You should also ask that the other side has NAT-Traversal and IPsec passthrough configured on their edge Router in this particular case as well.
What is the Authentication Method?
Authentication Method is usually a pre-shared-key (password) that the Remote side will share with you. You need to make sure that you have the same password so that you both have the same key on both ends. Sometimes, a Remote client will ask for RSA Certificates instead of pre-shared-keys but that is for another discussion.
If the answer to this question is pre-shared-key then you will need to find the best way to share this key with each other so that you can configure this on your ASA for their Peer IP.
What are the Phase 1 Settings?
With these settings, it is not necessary to understand each one in detail. All we need to do is make sure that our values match on both sides. I will do my best to provide a little bit of detail if you wish to pick the best for your needs but, in the end, your goal should be to match these values. All values in red are the default values that will be used when you create a policy.
Encryption: des | 3des | aes-128 | aes-192 | aes-256
The encryption is the way you plan on locking your data. The longer the bits, the harder it is to break the key. That is really oversimplifying encryption but in the end, it is easier to remember that the higher the bits, generally the safer/stronger it is. (The above is not in bit order, just encryption type then bit order. des is 64 bit and 3des is 192 bits)
Hash: md5 | sha-1
These are used for authenticating the source of an IP packet and verifying the integrity of its content. The VPN device will generate a hash and send it to the remote VPN device. It will use this to compare the hashes to check for packet integrity along with authenticating the remote device. If this value changes, then it can assume the segment was altered. As for which to choose for yourself, md5 has been broken before so I would recommend using sha-1. Now, md5 is faster to compute then sha-1 but usually this is negligible in network performance. Again, in the end, your goal should be to match the other sides settings.
Diffie-Helman (DH): 1 | 2 | 5 | 7
DH is used for the key exchange between your ASA and the Remote device. The larger the number, the more bits that are used, which in turn makes it that much more secure. Now, with that in mind, the larger the number, the longer the processing to use the keys. As always, we are just trying to match the other sides configuration for the most part so do not think too much into these values.
Lifetime(Seconds): 120 – 2147483647 (86400)
Lifetime is the amount of time Phase 1 will stay active until it needs to re-key the tunnel. You always want this value greater then the lifetime that you will use in Phase 2.
What are the Phase 2 Settings?
Phase 2 is the Second tunnel that will be built within the Phase 1 tunnel. If you have multiple networks that will be communicating with the remote side, each will get their own Phase 2. In most cases, every network combination will use the exact same Phase 2 settings. You will notice that the questions we need for Phase 2 are very similar to that of Phase 1 but do have some slight additions and options.
Encryption: esp-des | esp-3des | esp-aes | esp-aes-192 | esp-aes-256 | esp-null
You will see your options above are the same as they were in Phase 1, except for the esp keyword and null. The esp keyword is just letting you know that this being used on a ESP packet, which is what IPSec sends once traffic is encrypted. Encapsulating Security Payload (ESP) is its own protocol so it is not TCP or UDP so make sure the other side is allowing this protocol to their device. As for null, this means you can actually apply no Encryption on Phase 2 if you wish to do so but most never use this option.
Hash: esp-md5-hmac | esp-sha-hmac | esp-none
Again, we see that esp keyword but this just means this is being used on a ESP packet. As for hmac, this stands for ‘hash message authentication code’ but this just means it is using this a hashing authentication mechanism. You will notice that there is a none option now. This is if you wish to not add a HMAC to the Phase 2 Tunnels which could hinder security a little but would allow for faster processing. In the end, we just need to match this setting to what the remote location is using.
Diffie-Helman (DH): 1 | 2 | 5 | Not Available
DH is not required in Phase 2 and is allowed to be omitted. This is an optional addition and gets referenced as Perfect Forward Secrecy (PFS) in most cases. This will allow for each Phase 2 Tunnel to generate their own keys. This does mean more security but also adds more computing cycles that your ASA will have to go through per packet.
Lifetime(Seconds): 120 – 2147483647 (28800)
Amount of time that Phase 2 can stay active before it needs to re-key the Phase 2 tunnel. This value should be lower then your Lifetime in Phase 1.
Lifetime(Kilobytes): 10 – 2147483647 | Unlimited (4608000)
Kilobyte Lifetime is a lifetime value that was not available in Phase 1. Just as the Lifetime(Seconds), this will tell the ASA how much data can go over the Phase 2 Tunnel before the Phase 2 Tunnel needs to perform a re-key. In this case, which ever Lifetime (Seconds or Kilobytes) is met first, the Tunnel will re-key. You can also set this value to Unlimited which will, in essence, turn this feature off. This comes in handy since some remote devices do not Support Kilobyte Lifetimes.
What is the Encryption Domain?
Lastly, we need to know the interesting traffic that will be traversing this VPN Tunnel. We need to match these exactly on both sides or issues will arise. Each Source and Destination Network combination will build their own Phase 2 Tunnel. All we need to know on the ASA is to configure an ACL of our Local Source Networks to the Remote Destination Networks. Note, that if your Netmasks are off, that the tunnel may sometimes build but not in all scenarios.
For example, if we have a 192.168.100.0/24 configured as our Local Network.If the Remote side configures our Network as 192.168.100.0/22 on their side of the VPN, only our Local ASA will be able to build the Phase 2 VPN Tunnel for that network. This is because our /24 range fits inside of their /22 IP range. Their device will accept our proposal and build with our /24, even though they have /22 configure. The reverse, however, would not work since their /22 is larger the our configured /24.
Building the Site to Site VPN
Now that we have gotten most of our questions out of the way, we can begin configuring the ASA for the new Site to Site.
We will use the following as an example configuration with the following answers.
Policy Based VPN Peer IP: 50.56.228.50 Pre-shared-key: Th1nkN3t$ec Phase 1- Encryption: aes-128 Hash: sha-1 DH Group: 2 Lifetime: 86400 Phase 2- Encryption: esp-aes-256 Hash: esp-sha-hmac PFS (DH): NA Lifetime (s): 28800 Lifetime (k): 4608000 Encryption Domain: Local: 192.168.100.0/22 Remote: 172.16.240.0/24 Our Public IP for this tunnel (their peer IP) will be 50.57.228.150
ASA Code 9.x (8.3+)
I will be using a Crypto map called MyVPNMap but use the crypto map already configured on your device. If you do not have one, then please pick which ever map name works best for you. I will also be referencing my Internal Network name as INSIDE and my Outbound interface as OUTSIDE but please change these to match your device.
I like to first create my ACL that will be used as our Encryption Domain. We will also be creating object-groups for our Local and Remote Networks which will be useful for making changes later to the VPN and NAT.
object-group network MyVPN-LOCAL network-object 192.168.100.0 255.255.255.0 object-group network MyVPN-REMOTE network-object 172.16.240.0 255.255.255.0 access-list MyVPN extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE
Now that we have created our object-groups and ACL, we should create our Identity NAT for our Encryption Domain. This is to ensure that communication does not try to use any NATs that may prevent this traffic from traversing the tunnel. (Default PAT Outbound for example). If you do not understand the NAT below, do not worry too much. I do have a Article that breaks down NAT if you wish to understand more but for now, I would recommend using the NAT below in most cases.
nat (INSIDE,OUTSIDE) source static MyVPN-LOCAL MyVPN-LOCAL destination static MyVPN-REMOTE MyVPN-REMOTE no-proxy-arp route-lookup
With our NAT and ACL now configured, we will add our Phase 1 configuration for the VPN. Notice I set my policy as 100 but any value here will work so long as you are not overriding an existing policy.
crypto ikev1 policy 100 authentication pre-share encryption aes hash sha group 2 lifetime 86400
To complete the Phase 1 configuration, we will create our Tunnel-group so that we can bind our pre-shared-key with our Peer IP.
tunnel-group 50.56.228.50 type ipsec-l2l tunnel-group 50.56.228.50 ipsec-attributes ikev1 pre-shared-key Th1nkN3t$ec
With all of Phase 1 completed on your ASA, we will create our Transform Set (Phase 2 Encryption and Hash) for the VPN.
crypto ipsec ikev1 transform-set AES256-SHA esp-aes-256 esp-sha-hmac
Next, we will complete the VPN by configuring our Crypto map. Our Crypto map will bind our ACL and Phase 2 settings together with the Peer IP.
crypto map MyVPNMap 100 match address MyVPN crypto map MyVPNMap 100 set peer 50.56.228.50 crypto map MyVPNMap 100 set ikev1 transform-set AES256-SHA
If this is your first VPN on your ASA, you will need to enable IKEv1, set you Identity to your ASAs IP address and bind your new Crypto Map to your Outside interface.
crypto map MyVPNMap interface OUTSIDE crypto isakmp identity address crypto ikev1 enable OUTSIDE
When the Remote side has completed their end of the VPN, you should be able to bring the Tunnel up and pass traffic if al routing etc is already accurate.
Here is all of the configuration for 8.3+ below in one snippet.
object-group network MyVPN-LOCAL network-object 192.168.100.0 255.255.255.0 object-group network MyVPN-REMOTE network-object 172.16.240.0 255.255.255.0 access-list MyVPN extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE nat (INSIDE,OUTSIDE) source static MyVPN-LOCAL MyVPN-LOCAL destination static MyVPN-REMOTE MyVPN-REMOTE no-proxy-arp route-lookup crypto ikev1 policy 100 authentication pre-share encryption aes hash sha group 2 lifetime 86400 tunnel-group 50.56.228.50 type ipsec-l2l tunnel-group 50.56.228.50 ipsec-attributes ikev1 pre-shared-key Th1nkN3t$ec crypto ipsec ikev1 transform-set AES256-SHA esp-aes-256 esp-sha-hmac crypto map MyVPNMap 100 match address MyVPN crypto map MyVPNMap 100 set peer 50.56.228.50 crypto map MyVPNMap 100 set ikev1 transform-set AES256-SHA ! Only do the following if this is your first VPN crypto map MyVPNMap interface OUTSIDE crypto isakmp identity address crypto ikev1 enable OUTSIDE
ASA 8.0-8.2 Code
object-group network MyVPN-LOCAL network-object 192.168.100.0 255.255.255.0 object-group network MyVPN-REMOTE network-object 172.16.240.0 255.255.255.0 access-list MyVPN extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE ! This is an ACL used to prevent NAT from occurring. access-list nonat extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE ! This is where we bind the above 'nonat' ACL to state that this traffic is to be excluded from NAT nat (INSIDE) 0 access-list nonat crypto isakmp policy 100 authentication pre-share encryption aes hash sha group 2 lifetime 86400 tunnel-group 50.56.228.50 type ipsec-l2l tunnel-group 50.56.228.50 ipsec-attributes pre-shared-key Th1nkN3t$ec crypto ipsec transform-set AES256-SHA esp-aes-256 esp-sha-hmac crypto map MyVPNMap 100 match address MyVPN crypto map MyVPNMap 100 set peer 50.56.228.50 crypto map MyVPNMap 100 set transform-set AES256-SHA ! Only do the following if this is your first VPN crypto map MyVPNMap interface OUTSIDE crypto isakmp identity address crypto enable OUTSIDE
ASA 7.x Code
object-group network MyVPN-LOCAL network-object 192.168.100.0 255.255.255.0 object-group network MyVPN-REMOTE network-object 172.16.240.0 255.255.255.0 access-list MyVPN extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE ! This is an ACL used to prevent NAT from occurring. access-list nonat extended permit ip object-group MyVPN-LOCAL object-group MyVPN-REMOTE ! This is where we bind the above 'nonat' ACL to state that this traffic is to be excluded from NAT nat (INSIDE) 0 access-list nonat crypto isakmp policy 100 authentication pre-share ncryption aes hash sha group 2 lifetime 86400 ! This is the same as the tunnel-group command in the other code versions isakmp key Th1nkN3t$ec address 50.56.228.50 netmask 255.255.255.255 no-xauth crypto ipsec transform-set AES256-SHA esp-aes-256 esp-sha-hmac crypto map MyVPNMap 100 ipsec-isakmp crypto map MyVPNMap 100 match address MyVPN crypto map MyVPNMap 100 set peer 50.56.228.50 crypto map MyVPNMap 100 set transform-set AES256-SHA ! Only do the following if this is your first VPN crypto map MyVPNMap interface OUTSIDE crypto isakmp identity address isakmp enable OUTSIDE
0 Comments