cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1977
Views
0
Helpful
12
Replies

2xWAN uplink with 2 VPN ipsec on each

Piotr Pawlowski
Level 1
Level 1

Dear all,

I have router wiht 2 WAN uplinks. On both of them I need to have VPN ipsec connection.

With one VPN everythings works correctly. After adding second VPN configuration problem started.

I fugred out, that problem is in default gateway.

When I do:

no ip route 0.0.0.0 0.0.0.0 $GW_IP_of_primary_uplink$

ip route 0.0.0.0 0.0.0.0 $GW_IP_of_secondary_uplink$

VPN on first interface is not able to connect while VPN on second interface starts working.

What I would like to achieve is to have both VPN operating on my router.

Thank you in advance for any help.

Piotr

2 Accepted Solutions

Accepted Solutions

Can you try using the next hop ip addresses instead of the interfaces in all of your static routes?

View solution in original post

It is very good advice to use a next hop address in the static route rather than just the outbound interface. A static route such as ip route 192.168.200.0 255.255.255.0 GigabitEthernet0/2 will cause the router to generate an ARP request for each remote destination (which causes much more work on your router) and is dependent on the next hop router enabling proxy arp (and many networks are disabling proxy arp - especially on external connections - because it is perceived as a security risk). So if the next hop router does not enable proxy arp then this static route will not work at all.

Piotr says that 192.168.220.0 is unreachable. It is possible that this is because of the format of the static route. Please change the static route to use a next hop address and tell us if the problem improves.

HTH

Rick

HTH

Rick

View solution in original post

12 Replies 12

Richard Burts
Hall of Fame
Hall of Fame

Piotr

You have given us a little informaiton but not enough for us to give you very good answers. From what you have given us it sounds like the "interesting traffic" that will bring up a VPN follows the default route. So perhaps the answer might be that you need some routing for the destinations used for the first VPN that is different from the routing used for destinations in the other VPN. Perhaps if you post the configuration it would help us to give you better advice.

HTH

Rick

HTH

Rick

Hi Richard,

Thank you for your post.

Below you can find my config. I removed some sensitive/unused information from it.

!

version 15.2

service timestamps debug datetime msec

service timestamps log datetime msec

!

ip cef

!

multilink bundle-name authenticated

!

redundancy

!

crypto isakmp policy 1

encr 3des

hash md5

authentication pre-share

group 2

lifetime 28800

crypto isakmp key key_for_first_vpn address IP_of_first_VPN_peer

crypto isakmp key key_for_second_vpn address IP_of_second_VPN_peer

!

crypto ipsec transform-set GLIWICE esp-3des esp-md5-hmac

mode tunnel

crypto ipsec transform-set 1stCentral esp-3des esp-md5-hmac

mode tunnel

!

crypto map 1stCentral-map 2 ipsec-isakmp

set peer IP_of_second_VPN_peer

set transform-set 1stCentral

match address acl_access_to_1st_central

!

crypto map GLIWICE-MAP 1 ipsec-isakmp

set peer IP_of_first_VPN_peer

set transform-set GLIWICE

match address 190

!

interface GigabitEthernet0/0

description LAN

ip address 10.0.0.1 255.255.254.0

ip nat inside

ip virtual-reassembly in

ip policy route-map rm-to-1stCentral

duplex auto

speed auto

!

interface GigabitEthernet0/1

ip address IP_of_primary_uplink 255.255.255.252

ip nat outside

no ip virtual-reassembly in

duplex auto

speed auto

crypto map 1stCentral-map

service-policy output skype-policy-map

!

interface GigabitEthernet0/2

ip address IP_of_secondary_uplink 255.255.255.224

ip access-group 101 in

ip nat outside

ip virtual-reassembly in

duplex auto

speed auto

crypto map GLIWICE-MAP

service-policy output skype-policy-map

!

ip forward-protocol nd

!

no ip http server

no ip http secure-server

!

ip route 0.0.0.0 0.0.0.0 GW_IP_of_secondary_uplink

ip route 0.0.0.0 0.0.0.0 GW_IP_of_primary_uplink

!

ip access-list extended acl-route-servers-traffic

permit ip host 10.0.0.6 any

ip access-list extended acl_access_to_1st_central

permit ip 10.0.0.0 0.0.1.255 192.168.220.0 0.0.0.255

ip access-list extended acl_access_to_1st_central2

permit ip host 10.0.1.12 any log

!

ip sla auto discovery

access-list 1 permit 10.0.0.0 0.0.1.255

access-list 10 permit 0.0.0.0 255.255.254.0

access-list 101 permit ip any any

access-list 102 permit ip any any

access-list 110 deny   ip 10.0.0.0 0.0.1.255 192.168.220.0 0.0.0.255

access-list 110 deny   ip 10.0.0.0 0.0.1.255 10.0.100.0 0.0.0.255

access-list 110 permit ip 10.0.0.0 0.0.1.255 any

access-list 111 deny   ip 10.0.0.0 0.0.1.255 192.168.220.0 0.0.0.255

access-list 111 permit ip 10.0.0.0 0.0.1.255 any

access-list 190 permit ip 10.0.0.0 0.0.1.255 10.0.100.0 0.0.0.255

!

route-map all_gdansk_network_via_limes permit 10

match ip address 1 acl_access_to_1st_central2

set ip next-hop GW_IP_of_secondary_uplink GW_IP_of_primary_uplink

!

route-map rm-haarlem-via-task permit 10

match ip address acl-route-servers-traffic

set ip next-hop GW_IP_of_secondary_uplink

set ip next-hop verify-availability

!

route-map track_isp permit 10

match ip address 101

match interface GigabitEthernet0/1

set ip next-hop GW_IP_of_secondary_uplink

!

route-map track_isp permit 20

match ip address 102

match interface GigabitEthernet0/2

set ip next-hop GW_IP_of_primary_uplink

!

route-map rm-to-1stCentral permit 10

match ip address acl_access_to_1st_central2

set ip default next-hop  GW_IP_of_primary_uplink

!

route-map nat_isp2 permit 10

match ip address 110

match interface GigabitEthernet0/2

!

route-map nat_isp1 permit 10

match ip address 111

match interface GigabitEthernet0/1

!

control-plane

!

scheduler allocate 20000 1000

!

end

Piotr

Thank you for the additional information. In your original post it looked like you were doing one default route at a time. In this config there are two default routes at the same time. You probably should decide whether you want to have a primary route and a backup route (one at a time) or do load sharing (use both at the same time).

But there are likely to be VPN issues with either of the approaches unless you provide some additional routing information. For 1stCentral-map VPN to work its traffic must exit on interface Gig0/1. And for GLIWICE-MAP VPN to work then its traffic must exit on interface Gig0/2. The default routes will not accomplish that. So I suggest that you configure a route that will specify that traffic for 192.168.220 will exit on Gig0/1. And that you configure a route that will specify that traffic for 10.0.100 will exit on Gig0/2.

HTH

Rick

HTH

Rick

What I pasted is a current config.

After more diging I came into situation where both VPN are up, both networks 'after' VPNs are available. I achieved it with following config:

ip route 0.0.0.0 0.0.0.0 GW_IP_of_secondary_uplink

ip route 0.0.0.0 0.0.0.0 GW_IP_of_primary_uplink 10

ip route 10.0.100.0 255.255.255.0 GigabitEthernet0/2

ip route 192.168.220.0 255.255.255.0 GigabitEthernet0/1

However, right now whole LAN traffic is going via secondary uplink, which I can not accept.

When I give:

ip route 0.0.0.0 0.0.0.0 GW_IP_of_primary_uplink

ip route 0.0.0.0 0.0.0.0 GW_IP_of_secondary_uplink 10

ip route 10.0.100.0 255.255.255.0 GigabitEthernet0/2

ip route 192.168.220.0 255.255.255.0 GigabitEthernet0/1

192.168.220.0/24 network is unreachable.

What I am doing wrong?

Thanks in advance.

Hi Piotr,

Have you also tried adding a static route for the destination VPN gateways out of the respective interfaces? For example, if the peer IP address for crypro map 1stCentral-map is 1.1.1.1 and the peer IP address of crypto map GLIWICE-MAP is 2.2.2.2, you will have he following static routes. These will be needed to not only direct the interesting traffic out of the correct interfaces, but to direct the peer VPN gateways out of the correct interfaces as well.

ip route 10.0.100.0 255.255.255.0 GigabitEthernet0/2

ip route 192.168.220.0 255.255.255.0 GigabitEthernet0/1

ip route 1.1.1.1 255.255.255.255 GigabitEthernet0/1

ip route 2.2.2.2 255.255.255.255 GigabitEthernet0/2

Just added such configuration:

ip route 0.0.0.0 0.0.0.0 GW_IP_of_primary_uplink

ip route 0.0.0.0 0.0.0.0 GW_IP_of_secondary_uplink 10

ip route 10.0.100.0 255.255.255.0 GigabitEthernet0/2

ip route first_VPN_router_IP 255.255.255.255 GigabitEthernet0/2

ip route 192.168.200.0 255.255.255.0 GigabitEthernet0/2

ip route second_VPN_router_IP 255.255.255.255 GigabitEthernet0/2

and this caused, that both VPN site-2-site can not be established...

I am confused...

Can you try using the next hop ip addresses instead of the interfaces in all of your static routes?

It is very good advice to use a next hop address in the static route rather than just the outbound interface. A static route such as ip route 192.168.200.0 255.255.255.0 GigabitEthernet0/2 will cause the router to generate an ARP request for each remote destination (which causes much more work on your router) and is dependent on the next hop router enabling proxy arp (and many networks are disabling proxy arp - especially on external connections - because it is perceived as a security risk). So if the next hop router does not enable proxy arp then this static route will not work at all.

Piotr says that 192.168.220.0 is unreachable. It is possible that this is because of the format of the static route. Please change the static route to use a next hop address and tell us if the problem improves.

HTH

Rick

HTH

Rick

Well, that is what I have now:

ip route 0.0.0.0 0.0.0.0 GW_IP_of_primary_uplink

ip route 0.0.0.0 0.0.0.0 GW_IP_of_secondary

ip route 10.0.100.0 255.255.255.0 GW_IP_of_primary_uplink

ip route first_VPN_router_IP 255.255.255.255 GW_IP_of_primary_uplinks

ip route 192.168.220.0 255.255.255.0 GW_IP_of_secondary_uplink

ip route second_VPN_router_IP 255.255.255.255 GW_IP_of_secondary_uplink

Both VPN connections are establishe, as well as both VPN networks 'after' VPN are visible.

However, right now in show ip route I see, that gateway of last resort is my GW_IP_of_secondary_uplink . Some of the traffic is going via primary uplink, some goes via secondary.

Should I pllay wright now with PBR in order to specify which LAN hosts can access secondary uplink (and also secondary VPN )? In general I do not want to enable whole traffic via secondary uplink, because it is slower than primary one...

Thanks in advance.

Piotr

I am glad that changing the format of the static routes seems to have resolved the problem with VPN.

When you configure static default routes for both outbound interfaces, such as

ip route 0.0.0.0 0.0.0.0 GW_IP_of_primary_uplink

ip route 0.0.0.0 0.0.0.0 GW_IP_of_secondary

then you are telling your router that there are two equal paths to outside and the router will load share on the links. I believe that this is the current behavior that you describe. If you do not want load share because the second uplink is slower then I suggest that you change your approach to the routing. One solution that should work would be to have a single static default route which uses the faster uplink and to have static routes for VPN pointing to the second uplink. You might also consider configuring a floating static default route to provide failover to the second uplink in case of failure of the primary uplink. (If you do this you should probably also consider configuring IP SLA to track the primary uplink and to aid in failover.) You might also consider configuring some Policy Based Routing to send some types of traffic (perhaps traffic from specific hosts or perhaps some types of traffic such as Email) out the secondary uplink. This would result in most traffic using the faster primary uplink and would allow some traffic to use the slower secondary uplink.

HTH

Rick

HTH

Rick

Piotr Pawlowski
Level 1
Level 1

Thank you Richard and willwetherman for your suport and effort in solving my problem.

I will now try to configure PBR, but this is totally different topic, so this case can be treated as solved.

Thanks once again!

Piotr

I am glad that the VPN part of your problem is resolved and that our suggestions were helpful. Thank you for using the rating system to mark this question as answered. This will help other readers of the forum to recognize that helpful information is in this discussion. Good luck with the PBR configuration. If you run into issues feel free to start another discussion on that topic.

HTH

Rick

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco