Solved: Re: How to configure IPSec site-to-site VPN_On one site dual ISP and other site has one ISP

incognito · ‎03-31-2019

HELLO, team

Help me in this question

How to configure IPSec site-to-site VPN? One site (HUB) has dual ISP connection and other site (spoke) has one ISP.

In the beginning both HUB site and Spoke site had only one ISP and config looked like this:

crypto isakmp policy 1
encr aes
authentication pre-share
group 2
crypto isakmp key KEY address 212.15.60.100
!
!
crypto ipsec transform-set TRANS-SET-GRE-TUNNEL esp-aes esp-sha-hmac
!
crypto map CRYPTO-MAP 1 ipsec-isakmp
description to R1
set peer 212.15.60.100
set transform-set TRANS-SET-GRE-TUNNEL
match address IPSEC-traffic
!
interface Tunnel1
ip address 10.2.2.2 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
ip ospf mtu-ignore
tunnel source 216.11.45.100
tunnel destination 212.15.60.100
tunnel path-mtu-discovery
crypto map CRYPTO-MAP
!

Now we have this topology: One site (HUB) has dual ISP connection and other site (spoke) has one ISP.

Thanks in advance!

Richard Burts · ‎04-02-2019

If I am understanding your explanation correctly you have had a HQ and remote site with a single site to site VPN connection. Now you will be adding a second ISP for the HQ site and want to know how to configure the vpn. It is pretty clear that you will need to configure a second site to site vpn connecting the remote site to the second ISP. The question is how the vpn will operate.

In my experience there are 2 options. You can configure the vpns to provide redundancy (failover) or to provide load sharing.

1) to provide redundancy both HQ vpn are configured to carry the traffic of both HQ subnets and the traffic of the remote site. Each HQ router has a crypto map, that map points to the remote as the peer, and the access list to identify traffic for the vpn will include both HQ subnets. The remote router will have a single crypto map entry, that entry will have 2 peer addresses, and the access list to identify traffic for the vpn will include both HQ subnets. The result of this is that the remote peer will activate the vpn with the first (primary) peer and traffic will flow over that vpn. In the case where there is a problem and the primary vpn fails then the remote will negotiate and will activate the backup vpn.

2) to provide load sharing each HQ vpn is configured to carry the traffic of one of the HQ subnets. The crypto map of each HQ router will specify one of the HQ subnets communicating with the remote subnet. The crypto map of the remote will have 2 entries. One entry will have the peer address of ISP 1 and the access list to identify traffic for the vpn will specify one of the HQ subnets. The other entry will have the peer address of ISP 2 and the access list to identify traffic for the vpn will specify the other HQ subnet.

It would appear that the original poster wants to achieve both redundancy and load sharing. I can see how this could be implemented at HQ. Each router crypto map would be configured to carry the traffic of both HQ subnets, and the router in place between the HQ subnets and the vpn routers would forward traffic for one subnet to one vpn router and forward traffic for the other subnets to the other vpn routers. That middle router would check for failure of a vpn and in the case of failure would forward traffic for both subnets to the surviving vpn router. But I do not see how that can work for the remote. At the remote either there is a single crypto map entry with 2 peer addresses and the access list matches both HQ subnets or there are 2 crypto map entries and each access list matches one of the HQ subnets. I do not see a way for the remote to do both redundancy and load sharing.

HTH

Rick

HTH

Rick

View solution in original post

Richard Burts · ‎04-03-2019

I am glad that my explanation is helpful. You ask a very reasonable question

Then what is your advise/solution to realize at least something to closer to the main idea?

To answer that question I need to know which is the main idea. In terms of general traffic to the Internet you have achieved both load sharing and redundancy. For the site to site vpn you can have one or the other but not both. I do not know which is the more important one for your situation.

HTH

Rick

[edit] I do not see that Policy Based Routing would provide a solution for this.

HTH

Rick

View solution in original post

balaji.bandi · ‎03-31-2019

In the real world example of design if you looking full high availability / resilience you need to have dual links.

Since you are doing lab for testing (i am guessing this is lab, as per your diagram looks like GNS3).

Since hub have dual link, spoke can establish dual connection, failover to alternative link if hub has lost one ISP connection.

But if the spoke have lost connectvity there. is no redundent link so the site will be isolated here.

some design guide for referennce : (look at the limitations)

https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Aug2014/CVD-VPNWANDesignGuide-AUG14.pdf

https://www.cisco.com/c/dam/en/us/products/collateral/security/dynamic-multipoint-vpn-dmvpn/dmvpn_design_guide.pdf

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

incognito · ‎04-01-2019

Hello and thank you for the response

Let me add some details to my question. As I texted before: one site (HUB) has dual ISP connection and other site (spoke) has one ISP, but on the HUB site first subnet's traffic goes through ISP1 and second subnet's traffic goes through ISP2, in addition to this both subnet's traffics can communicate with each other (look at the image IPSec2.png). If ISP1 fails all traffics goes through ISP2, and when ISP1 comes to UP state again first subnet's traffic goes through ISP1 and second subnet's traffic goes through ISP2. And my question is: How to configure IPSec site-to-site VPN between HUB and Spoke?

Now my config looks like this without ISP2 link:

On HUB site:

crypto isakmp policy 1
encr aes
authentication pre-share
group 2
crypto isakmp key KEY address 216.11.45.100
!
!
crypto ipsec transform-set TRANS-SET-GRE-TUNNEL esp-aes esp-sha-hmac
!
crypto map CRYPTO-MAP 1 ipsec-isakmp
description to SPOKE
set peer 216.11.45.100
set transform-set TRANS-SET-GRE-TUNNEL
match address IPSEC-traffic
!
interface Tunnel1
ip address 10.2.2.1 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
ip ospf mtu-ignore
tunnel source 212.15.60.100
tunnel destination 216.11.45.100
tunnel path-mtu-discovery

On Spoke site:

crypto isakmp policy 1
encr aes
authentication pre-share
group 2
crypto isakmp key KEY address 212.15.60.100
!
!
crypto ipsec transform-set TRANS-SET-GRE-TUNNEL esp-aes esp-sha-hmac
!
crypto map CRYPTO-MAP 1 ipsec-isakmp
description to HUB
set peer 212.15.60.100
set transform-set TRANS-SET-GRE-TUNNEL
match address IPSEC-traffic
!
!
interface Tunnel1
ip address 10.2.2.2 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
ip ospf mtu-ignore
tunnel source 216.11.45.100
tunnel destination 212.15.60.100
tunnel path-mtu-discovery
crypto map CRYPTO-MAP

Richard Burts · ‎04-02-2019

If I am understanding your explanation correctly you have had a HQ and remote site with a single site to site VPN connection. Now you will be adding a second ISP for the HQ site and want to know how to configure the vpn. It is pretty clear that you will need to configure a second site to site vpn connecting the remote site to the second ISP. The question is how the vpn will operate.

In my experience there are 2 options. You can configure the vpns to provide redundancy (failover) or to provide load sharing.

1) to provide redundancy both HQ vpn are configured to carry the traffic of both HQ subnets and the traffic of the remote site. Each HQ router has a crypto map, that map points to the remote as the peer, and the access list to identify traffic for the vpn will include both HQ subnets. The remote router will have a single crypto map entry, that entry will have 2 peer addresses, and the access list to identify traffic for the vpn will include both HQ subnets. The result of this is that the remote peer will activate the vpn with the first (primary) peer and traffic will flow over that vpn. In the case where there is a problem and the primary vpn fails then the remote will negotiate and will activate the backup vpn.

2) to provide load sharing each HQ vpn is configured to carry the traffic of one of the HQ subnets. The crypto map of each HQ router will specify one of the HQ subnets communicating with the remote subnet. The crypto map of the remote will have 2 entries. One entry will have the peer address of ISP 1 and the access list to identify traffic for the vpn will specify one of the HQ subnets. The other entry will have the peer address of ISP 2 and the access list to identify traffic for the vpn will specify the other HQ subnet.

It would appear that the original poster wants to achieve both redundancy and load sharing. I can see how this could be implemented at HQ. Each router crypto map would be configured to carry the traffic of both HQ subnets, and the router in place between the HQ subnets and the vpn routers would forward traffic for one subnet to one vpn router and forward traffic for the other subnets to the other vpn routers. That middle router would check for failure of a vpn and in the case of failure would forward traffic for both subnets to the surviving vpn router. But I do not see how that can work for the remote. At the remote either there is a single crypto map entry with 2 peer addresses and the access list matches both HQ subnets or there are 2 crypto map entries and each access list matches one of the HQ subnets. I do not see a way for the remote to do both redundancy and load sharing.

HTH

Rick

HTH

Rick

incognito · ‎04-02-2019

Thank you, Richard for such a good explanation

As I understand you there is no the solution to realize both redundancy and load sharing. Then what is your advise/solution to realize at least something to closer to the main idea?

If I will configure PBR to realize this (as a solution)?

Richard Burts · ‎04-03-2019

I am glad that my explanation is helpful. You ask a very reasonable question

Then what is your advise/solution to realize at least something to closer to the main idea?

To answer that question I need to know which is the main idea. In terms of general traffic to the Internet you have achieved both load sharing and redundancy. For the site to site vpn you can have one or the other but not both. I do not know which is the more important one for your situation.

HTH

Rick

[edit] I do not see that Policy Based Routing would provide a solution for this.

HTH

Rick

incognito · ‎04-03-2019

I understand your point of view. Thank you so much!

Richard Burts · ‎04-05-2019

I am glad that my explanations have been helpful. Thank you for marking this question as solved. This will help other participants in the community to identify discussions that have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.

HTH

Rick

HTH

Rick

Tomahawk1 · ‎04-04-2019

@Richard Burts wrote:
I am glad that my explanation is helpful. You ask a very reasonable question
Then what is your advise/solution to realize at least something to closer to the main idea?

To answer that question I need to know which is the main idea. In terms of general traffic to the Internet you have achieved both load sharing and redundancy. For the site to site vpn you can have one or the other but not both. I do not know which is the more important one for your situation.

HTH

Rick

[edit] I do not see that Policy Based Routing would provide a solution for this.

James Tomahawk