Router IOS - Multiple VPN Tunnels - Each with unique interface ?

[rbuckshaw]

Hello,

I am in need of some advise.

Requirement for multiple low bandwidth VPn tunnels terminating on one IOS router, 3620. Need to apply rate limiting to individual vpns.

I would like 4 tunnels from customer 1 to terminate on IP address X

I would like 2 tunnesl from customer 2 to terminate on IP address X+1

I would like 1 tunnel from sustomer 3 to terminate on IP address X+2

etc...

Background:

I know I can have one map per interface and priortize the various peers, but I loose control lumping the tunnels together. I would like to rate limit I/O on the individual interfaces, and also keep the access lists under control.

The IP addresses must act as interfaces on the 100bt port. I thought about using Loopbacks, but got a little confiused with routing issues forcing the traffic throught the loopback to become interesting for encryption. Maybe I could use ISL and give up the address space?

Basically the route table looks like:

VPN1 - route -Target Termination1 via gateway x

VPN1 Target networks - route - via Target Termination1.

VPN2 - route -Target Termination2 via gateway x

VPN2 Target networks - route - via Target Termination2.

etc....

A little complication is that this router is behind a PIX interface (dmz) Pix segment currently a /24 addressed as x.x.x.1 and stand as .2. My 3620 f0/1 is a /29 set to x.x.x.3 Maybe a little un-orthodox but initial testing shows the pix can see the .3 and any loopback that I configure within the same /24 network. This is all connected via a 3524 switch. Side note: A good practice on networks that are getting complicated is to avoid router to pix, router to router connections. Every device connecting to a switchport makes for consistency and easier documentation. Span also is pretty handy.

Maybe my question is more a L2- L3 issue?

I was thinking that I could add more routers on the network segment as I use up the CPU on each one. Each router would have a handfull of IP interfaces to terminate these tunnels.

Thanks for the consideration.

[gmiiller]

I have done a little of this sort of thing using one router with multiple addresses assigned to loopbacks to terminate different crypto tunnels.

It is possible to use a loopback interface address as the address for crypto tunnels applied on other interfaces. The command is discussed elsewhere in this forum. Crypto map XXXXX source-interface loopbackX is roughly the format.

It's also possible to create subinterfaces on fast-ethernet ports and apply crypto maps to those. If you look at these options, use .1q not ISL as ISL has MTU issues that can add to the MTU issues IPSec already has.

BUT, the solution that many people try, which is subinterfaces on their crypto router with separate crypto maps, in conjunction with secondary addressing on their upstream router (and some crossover cables between different VLAN ports on their switch) is a no-go. When you use subinterfaces, they all inherit the mac address assigned to the primary interface, and so in the arrangement described the devices get a confused L2-L3 mapping.

This arrangement can be done with subinterfaces on each end (both crypto router and upstream router) Keep in mind that when using subinterfaces, there is some inheritance, so some options like CEF etc can't be set individually. I've also found some of the more colorful combiations of features like NAT/CEF/Crypto subinterfaces tend to have issues.

[b.mason]

One way to do this would be to use Loopbacks and tunnel interfaces. This way you can apply each crypto map to each tunnel interface. Obviously this means extra overhead as the IPSec tunnels are encapsulated with GRE. Cisco are working on changing the switching path so packets are treated by GRE first then IPSec (CSCdk59089, CSCdw03713).

EG.

interface Loopback1

ip address 1.1.1.1

!

crypto map connect-map1 local-address Loopback1

!

interface Tunnel1

tunnel source Loopback1

tunnel destination 2.2.2.2

crypto map map-name

This will allow you to run your routing protocols over the tunnels, etc..