ASA- Site to Site VPN
Step 1: Define Policies to be used (For Phase 1)
ISAKMP is used to establish the initial asymmetrically encrypted channels between the two endpoints so that they can securely negotiate a pair of one-way IPsec security associations (SAs).
crypto ikev1 policy 10 / crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
Enable ISAKMP on outside interface
crypto ikev1 enable outside (after 8.2)
crypto isakmp enable outside (Before 8.3)
Step 2: IPSEC Transform SET (Policies for Phase 2)
An IPsec transform set establishes the encryption and authentication (HMAC) methods to be employed by the IPsec SAs.
For ASA running 8.2:
crypto ipsec transform-set L2L<its just a name> esp-aes-256 esp-sha-hmac
For ASA running 8.3 and above:
crypto ipsec ikev1 transform-set L2L<its just a name> esp-aes-256 esp-sha-hmac
Step 3: Define Interesting traffic using access-list
access-list VPN-INTERESTING-TRAFFIC extended permit ip 10.254.254.0 255.255.255.0 172.16.254.0 255.255.255.0
Step 4: Create a group policy
group-policy 2.2.2.2 internal
group-policy 2.2.2.2 attributes
vpn-tunnel-protocol ikev1
Step 5: Now create a tunnel group to tell the firewall that its a Site to Site (l2l) tunnel & create a shared secret key
A tunnel group holds tunnel configuration parameters, namely the connection type and authentication method. Since we're using pre-shred key authentication, we need to name our tunnel group as the IP address of the remote peer. Also, notice that we must define the connection type (ipsec-l2l) before we can configure the pre-shared key.
***Tunnel group name is the IP address of the firewall/device on the other end of the tunnel***
tunnel-group 2.2.2.2 type ipsec-l2l ------> This creates a tunnel group with name 2.2.2.2 and defines it as l2l VPN type.
! Call the group policy in tunnel group.
tunnel-group 2.2.2.2 general-attributes
default-group-policy 2.2.2.2
! now we need to define a pre-shared key that needs to be used on both sides. Define pre-shared key for ipsec-attributes
tunnel-group 2.2.2.2 ?
configure mode commands/options:
general-attributes Enter the general-attributes sub command mode
ipsec-attributes Enter the ipsec-attributes sub command mode
tunnel-group 2.2.2.2 ipsec-attributes
pre-shared-key 12345cisco
Step 6 : Create & Apply a crypto map to Handle phase 2 tunnel:
Why do I need to create a crypto map?
Well, you have defined an ACL for interesting traffic but you haven't told where to use it, you have defined a tunnel group but its not in use (just sitting on your device), you have created an IPSec transform set but haven't applied it anywhere.
All these things are kept individually. We need something to tie them together and here comes CRYPTO MAP.
Crypto map ties together the IPsec transform set, access list, and tunnel group configured in the previous steps. First we match LAN-to-LAN traffic using our access list.
crypto map mymap 1 match address VPN-INTERESTING-TRAFFIC ----> Associating our ACL to match the interesting traffic with crypto map
Now what ASA has to do if it receives the traffic matching this ACL?
Dear ASA if you receive any traffic matching this ACL, then please set my peer to be 2.2.2.2 and use the policies defined in Transform set named as "L2L". Optionally we can define whether we want to run DH again to generate key material for Phase 2 by using PFS command. If we don't do it, then its gonna go ahead and use the same DH key material that it generated during phase 1 and usually we are totally fine with that.
crypto map mymap 1 set peer 2.2.2.2
crypto map mymap 1 set transform-set L2L (if ASA running 8.2)
crypto map mymap 1 set ikev1 transform-set L2L (if ASA running 8.3 or higher)
crypto map mymap 1 set pfs group 2 (OPTIONAL- to re-generate DH key material)
Step 7 : Now we apply the crypto map to outside interface and then we see how it works:
crypto map mymap interface outside
How it works?
To see the working , we need to start looking at our config from end .....
Lets say we generate a traffic from 10.10.10.2 host going to 20.20.20.2 host that exists on the other side of the tunnel.
Traffic reaches ASA1, ASA1 (ofcourse by routing ) knows that he needs to send this traffic out to its outside interface. Traffic reaches the outside interface.
Oh wait!
We have applied a crypto map on outside interface : crypto map mymap interface outside
Once ASA finds the crypto map on its outgoing interface, it says, hold on Mr Traffic, I see a crypto map applied on this interface and there is an ACL associated with this crypto map. Let me check if you match this ACL.
crypto map mymap 1 match address VPN-INTERESTING-TRAFFIC
Oh yes, you do macth the ACL, I have been asked to set my peer IP address as 2.2.2.2.
crypto map mymap 1 set peer 2.2.2.2
I am sorry but pause for a moment I can't let you go naked to the outside world, I need to encrypt you & encapsulate using the encryption method defined in the transform set that has been associated with the crypto map.
crypto map mymap 1 set transform-set L2L
Then it forwards the traffic out of its egress interface. ASA2 receives it and same dance happens there to decapsulate and de-crypt the traffic.
I hope you had fun learning it, so did I :) Are you looking for little more information, like packet level information?
You can refer this link here : or you can continue reading here. I am gonna try to explain:
http://ccie-or-null.net/2012/03/26/ike-main-mode-aggressive-mode-phase-2/
What exactly happens in background?
Sources :
1. http://ccie-or-null.net/2012/03/26/ike-main-mode-aggressive-mode-phase-2/
So far we know that IPSec secures the communication between two end points using ISAKMP, Diffie-Hellman, various encryption & hashing algorithms. But how exactly these all work together?
What happens after what?
IPSec will form its tunnel after IKE Phase 1 and Phase 2.
So there are two phases to form an IPSec tunnel:
1. IKE Phase 1
2. IKE Phase 2
Lets check them out one by one, inch by inch, get in the sync..
IKE Phase 1
IKE Phase 1 works in one of two modes, main mode or aggressive mode
As an initial difference, Main mode uses 6 packets, and Aggressive Mode uses 3 packets, we will see them later.
Main Mode:
In main mode both parties exchanging a total of 6 packets, I am also putting the config that is responsible for those respective packets.
So lets start:
From Initiator ----------->>>
pre-shared-key 12345cisco
Step 6 : Create & Apply a crypto map to Handle phase 2 tunnel:
Why do I need to create a crypto map?
Well, you have defined an ACL for interesting traffic but you haven't told where to use it, you have defined a tunnel group but its not in use (just sitting on your device), you have created an IPSec transform set but haven't applied it anywhere.
All these things are kept individually. We need something to tie them together and here comes CRYPTO MAP.
Crypto map ties together the IPsec transform set, access list, and tunnel group configured in the previous steps. First we match LAN-to-LAN traffic using our access list.
crypto map mymap 1 match address VPN-INTERESTING-TRAFFIC ----> Associating our ACL to match the interesting traffic with crypto map
Now what ASA has to do if it receives the traffic matching this ACL?
Dear ASA if you receive any traffic matching this ACL, then please set my peer to be 2.2.2.2 and use the policies defined in Transform set named as "L2L". Optionally we can define whether we want to run DH again to generate key material for Phase 2 by using PFS command. If we don't do it, then its gonna go ahead and use the same DH key material that it generated during phase 1 and usually we are totally fine with that.
crypto map mymap 1 set peer 2.2.2.2
crypto map mymap 1 set transform-set L2L (if ASA running 8.2)
crypto map mymap 1 set ikev1 transform-set L2L (if ASA running 8.3 or higher)
crypto map mymap 1 set pfs group 2 (OPTIONAL- to re-generate DH key material)
Step 7 : Now we apply the crypto map to outside interface and then we see how it works:
crypto map mymap interface outside
How it works?
Lets say we generate a traffic from 10.10.10.2 host going to 20.20.20.2 host that exists on the other side of the tunnel.
Traffic reaches ASA1, ASA1 (ofcourse by routing ) knows that he needs to send this traffic out to its outside interface. Traffic reaches the outside interface.
Oh wait!
We have applied a crypto map on outside interface : crypto map mymap interface outside
Once ASA finds the crypto map on its outgoing interface, it says, hold on Mr Traffic, I see a crypto map applied on this interface and there is an ACL associated with this crypto map. Let me check if you match this ACL.
crypto map mymap 1 match address VPN-INTERESTING-TRAFFIC
Oh yes, you do macth the ACL, I have been asked to set my peer IP address as 2.2.2.2.
crypto map mymap 1 set peer 2.2.2.2
I am sorry but pause for a moment I can't let you go naked to the outside world, I need to encrypt you & encapsulate using the encryption method defined in the transform set that has been associated with the crypto map.
crypto map mymap 1 set transform-set L2L
Then it forwards the traffic out of its egress interface. ASA2 receives it and same dance happens there to decapsulate and de-crypt the traffic.
I hope you had fun learning it, so did I :) Are you looking for little more information, like packet level information?
You can refer this link here : or you can continue reading here. I am gonna try to explain:
http://ccie-or-null.net/2012/03/26/ike-main-mode-aggressive-mode-phase-2/
What exactly happens in background?
Sources :
1. http://ccie-or-null.net/2012/03/26/ike-main-mode-aggressive-mode-phase-2/
So far we know that IPSec secures the communication between two end points using ISAKMP, Diffie-Hellman, various encryption & hashing algorithms. But how exactly these all work together?
What happens after what?
IPSec will form its tunnel after IKE Phase 1 and Phase 2.
So there are two phases to form an IPSec tunnel:
1. IKE Phase 1
2. IKE Phase 2
Lets check them out one by one, inch by inch, get in the sync..
IKE Phase 1
IKE Phase 1 works in one of two modes, main mode or aggressive mode
As an initial difference, Main mode uses 6 packets, and Aggressive Mode uses 3 packets, we will see them later.
Main Mode:
In main mode both parties exchanging a total of 6 packets, I am also putting the config that is responsible for those respective packets.
So lets start:
From Initiator ----------->>>
- The first packet is sent from the initiator of the IPSec tunnel to its remote endpoint, this packet contains the ISAKMP policy. In these policies there are 5 things that initiator sends to remote endpoint. You can remember them by the word HAGLE.
H- Hashing
A- Authentication
G- Group for Deffie Hellman
L- Lifetime
E- Encryption type
It also sends NAT-T information, telling the other side what type of NAT-Traversal it supports.
However, before the first two messages can be exchanged, the negotiation's initiator and responder must calculate what are known as cookies. These cookies are used as unique identifiers of a negotiation exchange. The two peers generate a pseudo-random number that is used for anticlogging purposes. These cookies are based on a unique identifier for each peer (src and destination IP addresses) and therefore protect against replay attacks.
(How a cookie is generated? check out here MyCookie :)
<<<------------ From Responder
2. The second packet is sent from the remote endpoint back to the initiator, this packet will be the exact same information (all those 5 things in HAGLE item) matching the ISAKMP policy sent by the initiator.
It also sends its NAT-T information back to initiator telling what type of NAT-Traversal it supports. There will be the same initiator cookies and this time responder cookies will be set to a value, since we have a responder yet.
From Initiator ------------>>>
3. The third packet is sent from the initiator to the remote endpoint, this packet contains the Key Exchange payload and the Nonce payload, the purpose of this packet is generate the information for the DH secret key.
Nonce stands for "number used once" or "number once" generated for a specific use, such as session authentication. A nonce is some value that varies with time, although a very large random number is sometimes used.
There will be an initiator cookies and Responder cookies will be set to 0, since we don't have a responder yet.
crypto ikev1 policy 10 / crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
<<<------------ From Responder
2. The second packet is sent from the remote endpoint back to the initiator, this packet will be the exact same information (all those 5 things in HAGLE item) matching the ISAKMP policy sent by the initiator.
It also sends its NAT-T information back to initiator telling what type of NAT-Traversal it supports. There will be the same initiator cookies and this time responder cookies will be set to a value, since we have a responder yet.
From Initiator ------------>>>
3. The third packet is sent from the initiator to the remote endpoint, this packet contains the Key Exchange payload and the Nonce payload, the purpose of this packet is generate the information for the DH secret key.
Nonce stands for "number used once" or "number once" generated for a specific use, such as session authentication. A nonce is some value that varies with time, although a very large random number is sometimes used.
0 comments:
Post a Comment