Multiple VPNs - One Interface

[GRANT3779]

Hi,

I have been reading up on creating site to site VPN using IPSEC. My question is, if I have a dedictaed "VPN" router at one site, say the outside interface is F0/0. I want to setup various VPNs from this site to a few remote sites using this router, but I want to be able to have each of these VPN connections have it's own interface, fo the purpose, of routing certain subnets over one VPN link and routing another subnet over the other sites VPN.

So from Hub site, I have one outside interface, but need IPSEC VPN to multiple spoke sites, and each site to have an Interfae I can route traffic through...if that makes sense?

Thanks

[Richard Burts · Accepted solution]

I am afraid that your post, as written, makes no sense to me. You start by saying that you have a router with one outside interface. Then you say that you need multiple interfaces. On the surface that would seem to indicate that you need to get a different router that will have multiple interfaces available for VPN.

Perhaps if you emphasize less the need for multiple interfaces and explain a bit more about what you really need there might be a way to accomplish what you need with the existing router.

I will start by suggesting that with one interface the router would have one crypto map. But one crypto map can have multiple instances of the crypto definitions within it with a unique instance for each remote peer. So for example you might have crypto map GRANT_map 10 for peer A and GRANT_map 20 for peer B and GRANT_map 30 for peer C. Within each instance of the crypto map you would identify a unique access list to identify traffic going to each peer. It might look something like this:

crypto map GRANT_map 10 ipsec-isakmp

match address peerA

set peer 1.2.3.4

crypto map GRANT_map 20 ipsec-isakmp

match address peerB

set peer 5.6.7.8

crypto map GRANT_map 30 ipsec-isakmp

match address peerC

set peer 9.10.11.12

ip access-list extended peerA

permit ip 10.1.1.0 0.0.0.255 172.16.0.0 0.0.255.255

ip access-list extended peerB

permit ip 10.2.2.0 0.0.0.255 172.17.0.0 0.0.255.255

ip access-list extended peerC

permit ip 10.3.3.0 0.0.0.255 172.18.0.0 0.0.255.255

Or perhaps you might consider using GRE tunnels with the IPSec for VPN. You could configure multiple tunnels each of which would source from the same outside interface and each one would terminate on a different peer. You could route certain subnets over tunnel 10 to peerA and route other subnets over tunnel 20 to peerB and route other subnets over tunnel 30 to peerC. Would that kind of solution satisfy your requirements.

HTH

Rick

[GRANT3779]

Hi Rick,

Apologies for my unclear post...however, you have answered exactly what I was looking for/asking so thank you for that.

Now regarding the Site to Site VPN and the GRE option, are there any reasons not to use GRE? Is this less secure? With the GRE option, I could indeed have a seperate tunnel interface for each of my VPNs so it would make more sense to use this. I assume with the Site to SIte VPN there is no way to have the seperate tunnel interfaces as you can with GRE?

If both use IPSEC, what is cons, of using GRE?

Thanks

[Richard Burts]

If you consider GRE as a solution by itself then it is not secure at all. GRE will take the original packet, encapsulate it in a new header and transmit the resulting packet without any encryption or any real protection.

So if you consider GRE by itself then you get routing capability but not security.

If you consider IPSec by itself then you get security but not routability.

What if you look at a solution that combines GRE and IPSec, then you get both routability and security.

The traditional approach to this uses a GRE tunnel (or multiple GRE tunnels) configured with the outside interface as the source and with destination at the remote peer (or at multiple remote peers) and a crypto map (with multiple instances if there are multiple peers) to control encryption of the traffic. You could implement this and it would work fine. There is a newer approach called Virtual Tunnel Interface (or VTI). It produces much the same result (you get tunnel interfaces that route and you get encryption of the traffic) but it does not use a crypto map. I would suggest that you look at this possibility since it does simplify the configuration (especially when there are multiple peers).

HTH

Rick

[GRANT3779]

HI Richard,

Just getting this configured and have a question  - in my other instance of the cryptop definitions, do I need to also add the transform set? Do I need to setup a new trasnform set, or can I reuse the one that is listed in my first crypto map instance? e.g

crypto map GRANT_map 10 ipsec-isakmp
set transform-set ABCD

match address peerA

set peer 1.2.3.4

crypto map GRANT_map 20 ipsec-isakmp

set transform-set ABCD

match address peerB

set peer 5.6.7.8

crypto map GRANT_map 30 ipsec-isakmp

set transform-set ABCD

match address peerC

set peer 9.10.11.12

[Jouni Forss]

Hi,

You should be able to use the same transform set.

Though I personally have had the habit of configuring a separate one for each VPN.

- Jouni