Build crypto over multiple public interfaces

[OliverDarvall]

Hi Guys,

We have a 2851 router being used as a Easy VPN Server. It is connected to the net via a fibre connection on GI0/1 through ISP1. Our remote sites connect successfully in to the router and the crypto sessions are built successfully.

We now have another fibre connection into the server that we would like to use on an ad-hoc basic to connect remote sites into our VPN, primarily as the new fibre is a high speed connection and we can thus get a "high speed" connection to the remote through it.

So when I remote switch a site over the the new ISP connection I change it's peer from x.x.x.y to m.m.m.n . The crypto connection requests through ISP2 does come in to the server. However it seems like the replies from those requestes are sent back to the remote through ISP1 and thus the crypto is never successfully established.

My static routes are as follows:

     ip route 0.0.0.0 0.0.0.0 x.x.x.x 30 permanent

     ip route x_network 255.255.255.240 x.x.x.x 20 permanent

     ip route m_network 255.255.255.248 m.m.m.m 20 permanent

Now if I change the gateway of last resort to "ip route 0.0.0.0 0.0.0.0 m.m.m.m 30" then the crypto is established, but after a minute or so all other crypto's on x.x.x.x start dying.

My question is though, how do I keep both fibres connected to the router simultaneously and have certain sites connect through ISP1 while other connect through ISP2.

[Jouni Forss]

Hi,

You should probably configure static route for each VPN peer IP you want to use the new ISP2 link.

You could also configure static route for each remote network that is found on the above mentioned VPN connections that are supposed to route through ISP2 link.

This way the default route could point through ISP1 while the ISP2 link would be utilized by using more specific static routes.

I am not completely sure but you might be able to just add the remote VPN peer IP addresses static routes to your routing table and configure the L2L VPN connection crypto maps so that they automatically add routes for the remote network. This would result in less configurations on the actual device.

Hope this helps

- Jouni

[OliverDarvall]

Jouni, the remote sites connect to the net via ADSL and as such have no fixed IP addresses. That makes static routes basically impossible does it not ?

[Jouni Forss]

Hi,

So are we talking about a situation where all of your VPN connections to this central device are dynamic in nature? I mean each remote site mainly uses DHCP IP address and automatically connect to the central site without the central site really having the knowledge from which IP address the connection comes from?

If that is the case then I am not really sure what should be done as I have not done such a migration myself.

My first thought was to separate each ISP link to its own VRF locally on the router so each could have its own default route/routing table. I guess this would mean that the LAN interface would also have to be set on its own VRF. Then you would probably have to configure routing between the ISP1 VRF and the LAN VRF and ISP2 VRF and the LAN VRF so that the correct remote network would be reachable (adverticed) from the correct ISP VRF.

Or perhaps there is an option to forget the VRFs completely and use PBR (Policy Based Routing) and handle the traffic so that the traffic sourced from ISP2 public IP are always forwarded to ISP2 next hop and traffic sourced from ISP1 public IP are always forwarded to ISP1 next hop.

The above mentioned things are not something that I handle day to day but come intouch through my work. So I can't say for sure if they would be a workable solution in your case, but those are the options that come to mind.

Naturally if we were talking about L2L VPN connections only (using Static IP addressing) the situation would be a lot easier.

- Jouni

[OliverDarvall]

JouniForss wrote:
Hi,
So are we talking about a situation where all of your VPN connections to this central device are dynamic in nature? I mean each remote site mainly uses DHCP IP address and automatically connect to the central site without the central site really having the knowledge from which IP address the connection comes from? CORRECT       

What I am wondering is why when the VPN connection requests come in on the ISP2 interface, would the replies be sent back through ISP1. I understand that it is sent there because of the gateway of last resort. But shouldn't the server know thus that the remote request came in on ISP2 and send the reply though ISP2. It thus seems to me that the remote address is not added into the routing tables. Can this be done automatically ?

[Karsten Iwen]

As you have already realized, the return-packets are only routed based on the routing-table.

But there could be a way to achieve it with one router. I never tested it as I typically have two routers for the main-office. But here is a way that could work and is worth a try:

Configure two VPN-groups that are matched on two different isakmp-profiles. These profiles reference your virtual-templates.

Configure two IPSec-profiles and attach your isakmp-profiles. On the IPSec-profile you can configure a reverse routing gateway. With that it should be possible to connect to x.x.x.y with GroupA and the routing is done with the main routing table. If the client connects to m.m.m.n with Group2, the encrypted packets are routed to gateway m.m.m.m

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[OliverDarvall]

That sounds like an idea ! The only thing that I am not quite seeing immediately is where I would link the new profiles/templates to a specific isp/sub interface ?

Herewith some config sections :

crypto isakmp profile IKE_Profile-1

   match identity group Identity-Group

   client authentication list default

   isakmp authorization list Group_Auth

   client configuration address respond

   virtual-template 1

interface Virtual-Template1 type tunnel

tunnel mode ipsec ipv4

tunnel path-mtu-discovery

tunnel protection ipsec profile IPsec_Profile-1

end

crypto ipsec profile IPsec_Profile-1

set transform-set VPN_Set

set isakmp-profile IKE_Profile-1

crypto ipsec transform-set VPN_Set esp-3des esp-sha-hmac

crypto isakmp client configuration group Identity-Group

key xx_my_key_Xx

dns 192.168.1.200 192.168.1.201

pool Mobile_Pool

acl 100

save-password

max-users 5000

[Karsten Iwen · Accepted solution]

A solution would be to use two routers, one for each ISP-connection. With that you would have real redundancy for your hub. To make sure that the traffic reaches the right exit-point, you could use reverse-route-injection and a dynamic routing protocol.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[OliverDarvall]

How about if I brought ISP2 in through another new router (say Rx) and then use Rx to nat everything from ISP2 to the ISP1 interface on my main router ?

Would the NAT translations/tables thus resolve the "routes" problem ?

[Karsten Iwen]

with a second router there wouldn't be anything to be NATted.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[OliverDarvall]

Sorry, my post was a bit vague. I do not have another 2851 to run it as a separate VPN router, so I was wondering how about using a 1841 to NAT ISP2 traffice to ISP1 interface :

     ip nat source static x.x.x.y m.m.m.m extendable

[OliverDarvall]

In the end I just could net get it working on a single router. I managed to get a second one though and everything worked very soon after that with a simple peer change on the end points, and a few route changes on our core switch.

[Karsten Iwen]

After thinking about it again, it should be quite simple with a local policy:

ip access-list extended ISP2-LOCAL-IP

  permit ip host m.m.m.n any

!

route-map LOCAL-ISP2 permit 10

  match ip address ISP2-LOCAL-IP

  set ip next-hop m.m.m.m

!

ip local policy route-map LOCAL-ISP2

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[OliverDarvall]

That has helped ! My crypto's now build up to Up Idle state, but at least that is progress.

Would a "ip route isp2network isp2mask isp2gateway" notmbe equivalent to the local policy ?

[Karsten Iwen]

Would a "ip route isp2network isp2mask isp2gateway" notmbe equivalent to the local policy ?

no, an "ip route" is always based on the destination-address while this local policy is based on the source address.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni