Cisco ASA Site-to-Site IKEv2 IPSEC VPN

Hello Waleed

It is possible to create multiple VPNs between the same two peers. You can also have one tunnel use IKEv1 and the other IKEv2 and have the same sa for both. You shouldn’t have any issues as long as you use different ACLs to define the VPN traffic and a different transform-set for each. The more pertinent question is why would you implement something like this rather than having a single tunnel? Unless there are exceptional circumstances, this introduces a level of complexity that is not necessary.

I hope this has been helpful!

Laz

Hi All,

Anyone done this before successfully?
Create site to site vpn from Main(HQ) site Cisco ASA 5512x (Static IP) to remote site Cisco RV325 (Dynamic IP). Please advise any help appreciated.

thanks,
Pat

Hello Patrick

For this configuration, you will be required to set up the configuration so that the client device (RV325) initiates the tunnel. The ASA cannot initiate the tunnel since it does not know the dynamically assigned IP address of the device.

The following documentation lays the groundwork for the configuration of such a scenario. Although the devices are not exactly the same as those you describe, it shows the basic principles involved, and you should be able to apply them to your scenario.

If you have additional questions as you configure your devices, please feel free to let us know!

I hope this has been helpful!

Laz

I have an environment with 2 sites(offices) connected via IPSec Site-to-site VPN on public IP. This working as it should. Site A 192.168. X.X and SiteB 10.5.X.X

I have Remote Access VPN configured on both sites. I created an IP pool Site A 192.168.110.0/24 and Site B 10.5.110.0/24.

For Site A, internal networks are 192.168.X.0 the (X indicates VLANS). When connected to the Remote Access VPN on Site A (192.168.110.X), the users can reach Site A internal resources.

For Site B, internal networks are 10.5.X.0 the X indicate VLANS. When connected to the Remote Access VPN on Site B (10.5.110.X), the users can reach Site B internal resources.

Now the challenge is: While connected to Remote Access VPN on Site A (192.168.110.X), How can i reach local resources on Site B (10.5.X.0)? And vice versa.
Will appreciate your swift response and available to provide more details if needed.

Thanks.

Hello Samuel

I took the liberty of creating a diagram of your network based on your description:


Now I’m not sure where your routing takes place at each site, but I assumed the VPN devices simply terminate the VPN, and you have another device, such as a Layer 3 switch that does the internal routing. It may be that your VPN device does all your routing, but the principle is the same.

Now in order for all of your VLANs at Site A to communicate with all of your VLANs at Site B, it is simply a matter of routing. It actually doesn’t directly involve your VPN configuration at all. You can consider the VPN connection as simply a direct connection between the sites.

In order to resolve your problem, all routing devices must be “aware” of all of the subnets and how to reach them. Based on my diagram the following must exist:

  • The Site A L3 switch must have a routing table entry for all of the 10.5.X.0/24 subnets with a next hop of the Site A Router
  • The Site A router must have a routing table entry for all of the 10.5.X.0/24 subnets with a next hop of the Site B Router
  • The Site B router must have a routing table entry for all of the 10.5.X.0/24 subnets with a next hop of the Site B Switch

Similarly, the same must be true for the subnets in Site A:

  • The Site B L3 switch must have a routing table entry for all of the 192.168.X.0/24 subnets with a next hop of the Site B Router
  • The Site B router must have a routing table entry for all of the 192.168.X.0/24 subnets with a next hop of the Site A Router
  • The Site A router must have a routing table entry for all of the 192.168.X.0/24 subnets with a next hop of the Site A Switch

Now all of this can be configured using static routing, or using a routing protocol like OSPF or EIGRP. Depending on how you have created your VPN tunnel, you may need to put in some special configurations, because a pure IPSec VPN tunnel will not support multicast traffic, which is necessary for dynamic protocols to work.

I hope this has been helpful!

Laz

Thanks so much for your effort Laz, i do really appreciate.

Your explanation does makes things clear in an ideal situation. Now considering that:

  1. Currently routing between all internal subnets is done on the firewall. The ASA is the gateway of all internal subnets on both sides and pretty much i am using static route S* 0.0.0.0 0.0.0.0 via the ISP. So there is no L3 switch/router between.
  2. The VPN IP pool for both sides are pretty much not known to the Network (i.e the switch). I just created a Pool from (Configuration ->Remote Access VPN -> Network Client Access -> Address Assignment -> Address Pool). There is no interface configured for it nor VLAN configured for the pool on the switch. So 192.168.110.X and 10.5.110.X are the pools assigned to users when they connect via Cisco anyconnect Secured Mobility Client.
  3. Right now, it does work by configuring a NAT Rule Example: Source int (any) Destination int (any) Source ( The VPN pool 192.168.110.0/24) Destination ( Are the internal resources of both Site A and Site B) then Action: Translated: Packet (192.168.50.200) this is an imaginary IP which doesn’t exist no where.
    But with above it worked, only that there are still some issues where we need traffic both ways. I did mange with further Nating rule.

Considering above scenario where the IP pools are not know to the Network, i guess this is the main issue.
I don’t think this is best practice and would appreciate your help in redefining the IP Pool setup side.

Thanks.
Samuel

Hi ,
you have the below policy , but the policy did not used anywhere ?

ASA1 & ASA2#
(config)# crypto ikev2 policy 10
ASA1(config-ikev2-policy)# encryption aes
ASA1(config-ikev2-policy)# group 2
ASA1(config-ikev2-policy)# prf sha
ASA1(config-ikev2-policy)# lifetime seconds 86400

Thanks

Hello Sims

When you create a policy, you give it a priority number. In this case it is 10. Whenever an IKEv2 tunnel is initiated, the device will automatically look for any policies that have been created in the device and will use them, according to the priority. You can use multiple policies if you have multiple peers.

Now in order to enable the policy, you must initiate the crypto ikev2 enable OUTSIDE command in order to apply the policy to the outside interface, something that was indeed done in the lesson.

I hope this has been helpful!

Laz

Hello Samuel

Even if you don’t have L3 switches, and all your routing takes place on the ASA, the principle is the same. However, I have a feeling that your topology is a little different, so let me ask a few questions to gain a better understanding of the topology.

  1. If you have multiple VLANs at each site, how are those VLANs separated? How does each VLAN connect to the default gateway (which is the ASA)? Is it on a per interface basis? In other words, do you have each inside interface of the ASA serve as a gateway for each of the internal VLANs? Are you using a “router on a stick” topology to gain inter-VLAN routing? Can you give us a clearer picture of the on-site topology beyond the VPN?
  2. You mention that your users are using Anyconnect Secured Mobility Client. This should not be necessary on a site to site VPN, as end users that are physically at SiteA or SiteB will be oblivious to the existence of the VPN. If however you have users that are off site, then yes, you would use this, but it would be a separate and independent configuration than that of the site to site connection.
  3. Assuming a pure site to site VPN, for internal routing such as this, NAT rules should not be involved. For this reason, we need a clearer picture of your topology and your configuration.

These clarifications will further help us to help you in your troubleshooting and configuration.

Laz

Hello Laz,

Thanks for your effort on this. I managed to get it work as you initially suggested.

Thanks.

1 Like

Hi dear friend. i want to configure 2 site to site vpn on one Cisco ASA.i must write 2 phase 1 policy for per vpn or 1 phase 1 for 2 vpns.
phase 1
crypto ikev1 policy 14
authentication pre-share
encryption aes
hash sha
group 2
lifetime 3600

Hello Cemil

If you create multiple VPNs on an ASA, you can use the same phase 1 policy for all of them assuming the policy is valid and configured on the other end of each VPN as well. Note that you don’t actually choose the policy, but the polices are defined with their priority numbers. You can assign up to 20 IKE policies. How they are applied is described in this Cisco documentation like so:

When IKE negotiations begin, the peer that initiates the negotiation sends all of its policies to the remote peer, and the remote peer tries to find a match. The remote peer checks all of the peer’s policies against each of its configured policies in priority order (highest priority first) until it discovers a match.

A match exists when both policies from the two peers contain the same encryption, hash, authentication, and Diffie-Hellman parameter values. For IKEv1, the remote peer policy must also specify a lifetime less than or equal to the lifetime in the policy the initiator sent. If the lifetimes are not identical, the ASA uses the shorter lifetime. For IKEv2 the lifetime is not negotiated but managed locally between each peer, making it possible to configure lifetime independently on each peer. If no acceptable match exists, IKE refuses negotiation and the SA is not established.

So for each VPN you create, the policies are examined one at a time until a match is made between the two endpoints.

I hope this has been helpful!

Laz

Hi Rene
I see that we create an ikev2 policy but I don’t see it referenced anywhere. I may be missing something but how is the policy actually used? On some of our firewalls at work we have several ikev2 policies defined, some of which use commands deprecated in later ASA software versions, so how do I establish which ones are in use so I can determine to which software version I can upgrade?

Thanks,
Phil.

Hello Phil

You don’t need to reference an IKEv2 policy anywhere because an ASA will always use the policy you create by default. If you have more than one policy configured, it will use the first policy (based on policy number) that it finds configured on the device. More info about this can be found here:

For migrating from an older ASA to a newer one where syntax has changed, it all depends on the old and new versions. Syntax has changed in different ways over the versions and you’ll have to research processes for your specific situation. Take a look at this example that is discussed in the Cisco community forum:

For particular versions and platforms, a good starting point may be at this link as well:

I hope this has been helpful!

Laz

Thanks for your reply Laz. That’s very useful.
So are we saying then that, if we have, for example, crypto policy 1, crypto policy 10, crypto policy 20 etc, it will only use number 1 and policies 10, 20 etc are redundant? Or is it the case that the ASA negotiates with its peer and uses the first policy that the two of them have in common?

Update: I see now that you have already answered this in your reply to Cemil in the previous question.

Hello Phil

Yes, that’s correct. Just for reference, and for other readers, here is the response to Cemil that contains your answer.

I hope this has been helpful!

Laz

Hi,
I can reach r2 from R1 and not from R2 r1 ,
What could be the issue

Thanks

Hello Sims

I’m not sure I understand. You can reach R2 from R1 but not R1 from R2? Can you clarify? Also, let us know how you tested reachability. Did you use ping? Let us know so we can help you further…

Laz

Hello
when using preshared keys there seems to be 1 for the crypto map and 2 for the tunnel settings
but your lessons only shows it in the tunnel settings
Can you explain?

crypto map outside_map 1 match address outside_cryptomap
crypto map outside_map 1 set pfs group20
crypto map outside_map 1 set peer xxx.xxx.xxx.xxx
crypto map outside_map 1 set ikev2 ipsec-proposal AES256sha512
crypto map outside_map 1 set ikev2 pre-shared-key *****
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside


tunnel-group xxx.xxx.xxx.xxx type ipsec-l2l
tunnel-group xxx.xxx.xxx.xxx general-attributes
 default-group-policy GroupPolicy2
tunnel-group xxx.xx.xxx.xxx ipsec-attributes
 ikev2 remote-authentication pre-shared-key *****
 ikev2 local-authentication pre-shared-key *****

Hello Neil

The configuration of a pre-shared key on the crypto map is optional. As in the lesson, if you don’t specify it, then it won’t be used. In the configuration you are sharing, it is used, and must be applied at both ends of the tunnel. More info on this command can be found here:

Similarly, when creating the tunnel group, you can specify either a symmetric or an asymmetric pre-shared key for ikev2. In the example in the lesson (and in your post), an asymmetric pre-shared key arrangement is being used, where each end of the tunnel uses a different pre-shared key. As you can see in the lesson, the local-authentication preshared key must match the remote-authentication preshared key of the device on the other end of the tunnel. But this too is optional. More on these commands can be found here:

I hope this has been helpful!

Laz