multipoint and point to point IPsec with Tunnels questions @#@#

[g-serghiou]

Hi All,

long time to write here as i have been 'away' from the router scene (some years now ) ....

I am in need of understanding some new configurations done at the router here where i am. they deployed IPsec in tunnel mode.

the scenario is this :

from one central node (central offices) we connect to other offices (remote) using IPsec with Tunnels.

i have read some manuals online, and i would like to start by asking some easy questions at first, and then proceeding with some more details, regarding the current configuration.

my first question is :

I have read some examples (from cisco documents online), using point to point IPSec tunnel from router A to router B. Instead of creating a CRYPTO MAP  entry , they use the CRYPTO IPSEC PROFILE command. The CRYPTO PROFILE is then used in the TUNNEL configuration.

The tunnel inteface states the local FastE address as the source and the appropriate destination address.

My questions are :

A.

Since there is no CRYPTO MAP entry, to specify which transform set to use, and which traffic to 'encrypt' (by means of ACLs), how does the router decide which traffic to encrypt ?

B. in multipoint IPSec VPN configurations, the CRYPTO PROFILE command is not used. here, the normal CRYPTO MAP command is issued and transform set and ACLs specified. then the crypto map (set) is applied to the interface (or subinterface). normal configuration of tunnels exist. Why don't we use the CRYPTO PROFILE command as in question A and instead use CRYPTO MAP, and then applied to the physical interface ? What is the difference here and could i use the CRYPTO PROFILE instead of CRYPTO MAP scenario in a multipoint IPSEC tunnel scenario ??

I hope i explained what my questions are ! Please ask me any questions you need , to make sense of my writing.

I attach the document for point to point IPSEc with tunnels which i talk about !

Thanks,

George

[Bastien Migette]

Hello Georges,

I think you can have a look at this

https://supportforums.cisco.com/community/netpro/security/vpn/blog/2010/12/08/advantages-of-vti-configuration-for-ipsec-tunnels

To answer your questions, a tunnel interface cipher every traffic that is routed to this interface.

The tunnel interfaces supports multicast, which means you can run a dynamic routing protocol through it.

All routes learnt via the tunnel interface will be routed through the tunnel, and therefore encrypted.

You can use PBR or static routing as well.

For the multipoint configuration, you can obviously use tunnel interface, to do so, you can set use 'tunnel mode gre multipoint' command,and then apply the ipsec profile to the tunnel interface, this is pretty common DMVPN configuration.

I personnally think IPSEC Tunnel interaces are more easy to maintain and troubleshoot, but crypto map are still supported and you might still have to use them for devices that don't handle VTI Interfaces.

I hope this help.

[g-serghiou]

Hi Bastien,

thanks for the reply,

if I understand correctly, (as i said, long time to touch a router, and only qualified as a ccna long time ago) ...

ipsec vpn used on interfaces-subinterfaces was limited, cause it has no support for multicast traffic, and this made things difficult especially for dynamic routing protocols ?

and if so, is the 'solution' to this (and maybe other things, not apparent to me right now) Tunnels ?

i have already read some things about DMVPN (cisco documentation) and i have found my answers to my questions above (i can use both scenarios , CRYPTO MAP , and CRYPTO PROFILE on the tunnel interface) i will have a better read tomorrow and read the whole paper !

so to come back to my scenario at work. am i right to say this ? They could use IPsec over subinterfaces, but they couldn't use Routing protocols ?

so they used tunnels, so that they could pass routing protocols (or other multicast traffic) over the encrypted link ?

if my above assumptions are correct, then if i had no dynamic routing protocols, and no need for multicast traffic, then there is no 'real benefit' using tunnels in this case ?

Thanks,

George

Message was edited by: g-serghiou

[Bastien Migette]

Hello Georges,

If you use Crypto map, you can't use Multicast, but that doesn't means you can't use dynamic routing protocols, as you can always define a unicast neighbor using the neighbor command under the routing protocol configuration.

Now, if you have no need for multicast, you can choose between crypto map and tunnel interfaces. As I told you, I think tunnel interfaces are a bit more straightforward to maintain because you don't have to use crypto ACLs, only route traffic to be protected through the tunnel, but that's really something personnal.

A thing is that you can't filter particular traffic to be ciphered as you can do in a crypto ACLs (in case you want to protect only a certain kind of traffic, but that can be done using PBR).

I like as well the fact that tunnel end are routed interfaces, so you can ping them to monitor the tunnel.

Now I would say that if you are more confident with crypto maps, and if that suits your need, there's no real needs to go to IPSEC tunnels interfaces.

I hope this answer your questions.

[g-serghiou]

Hi Bastien,

i am sorry, but im a bit confused....

you said

"

Now I would say that if you are more confident with crypto maps, and if  that suits your need, there's no real needs to go to IPSEC tunnels  interfaces.

"

in the configuration i have here, on the main router, they have configured multiple tunnels (15 of them), then have 15 Crypto ACLs, and 15 CRYPTO MAP (with different seq num) .

Then all these Tunnels have as source, the same Fastethernet subinterface. then the CRYPTO MAP set is aplied to the subinterface.

an the same goes on the remote routers, having only 1 Tunnel, 1 acl, 1 crypto map , and the source for the tunnel is a fastE subinterface with the crypto map command !

I understand now the working of the above configuration, but from what i see i could use DMVPN (not really needing it as i wont be seinding  multicast traffic, but the configuration would be much less and tidy !  Am i right to say this ??

What I am trying to figure out, is why havent they configured 15 subinterfaces onthe main router, and just use CRYPTO MAPs to 'secure' traffic between them, using subinterfaces without the need for tunnels ?

I am sorry if I seem to ask the same thing over and over. ! lets see if i get it right this time

Thanks,

George

[Bastien Migette]

Hi George,

You are right, it would have been, to my sense, more easy to either use crypto map on subinterfaces, or tunels with crypto profiles applied on it, but as you can see you can make a tunnel and secure the tunnel traffic with crypto map, but that means that you have to make an ACL that match tunnel's traffic, so if you change src/dst you have to modify ACLs. As well, you have to set the transform set (the one used by the crypto map) as transport, otherwise you will double encapsulate the outgoing traffic.

Just to let you know, by default a tunnel interface use GRE protocol. You can use GRE over IPSEC to have  a secure tunnel(either via crypto maps or ipsec profile). The advantage of GREoIPSEC was to have a tunnel that supports multicast. In this case you had to configure crypto maps that cipher tunnel's traffic. Now, since 12.3 (I think), you have IPSEC VTI, that have pretty the same functionnalities than GREoIPSEC with less configuration, that doesn't means GREoIPSEC do not work, but it has more headers (4 or 8 byte for GRE Header) and the except if you want to encapsulate non IP traffic into your tunnel, that has no real interest. IPSEC VTI are configured by using tunnel mode ipsec ipv4 and tunnel protection ipsec profile XXX in interface tunnel configuration.

Regarding the DMVPN Feature, you would have two options:

Hub and spoke (Phase 1) design : On the main site, you would have only 1 tunnel interface, which will use GRE Multi point, to the remote site, and remote site will have a gre point to point int to hte main site. This allow to add remote routers without configuring the HUB.

You can have the spoke to spoke (phase 2) design, which have a few more configuration, but allows remote router to dynamically initiate tunnels between them, to less resources utilization on the main router.

Is it clear now ?

[g-serghiou]

Hi Bastien,

things are indeed clearing up  now...especially now that i have studied abit about IPsec , VTI etc... i also studied the configurations of main router here and the remote router(s) and i am forming a much better idea how things work.

your answers have been very helpful. Thanks very much for the replies.

I would like to ask now about Routing  now

so far i was used to configuring nice plain old Frame Relay connections ! I am on this side, you are on that side , IPs on interfaces were on the same subnet and providers took care of things with dlcis ....

alas...thinking the old way, i was 'surpised' to see that my IPs on the endpoints are no longer on the same subnet (I forgot about the providers 'cloud' in the middle).... now i am aware of  that !

so here it comes... my remote sites have no need to use routing protocols. so static routes are being used. Most of them, and i say most of them because the configurations were undertaken by different people, each of them delivering a configuration they thought works , or is the ideal.

the configuration on one of the remote sites (that i have ckecked) has a default route, outgoing through its tunnel interface (which has a FastE subint as source).

then another static route to the Central router's Subinterface IP (which is used as a source for the tunnels on the central router) outgoing from to ISP provider's IP address 'opposite' to the remote routers Subint IP.

is the last static route needed? why cant i just forward all traffic through the tunnel (which has the subint as a source) and the ISP Provider take care of routing to the central router IP ???am i missing something here ?

Or lets put it another way. What static routes would you use to route all traffic to the other endpoint ?

Thanks,

George

this is a sample configuration on one of the remote routers.

the ISP IP opposite to my FastE0/0.1 is  10.154.10.54 ....

the Central Routers IP on the subinterface used as a source for the tunnels is 10.154.30.1

please look at the static routes and commend on them !

====================================================================================

interface Tunnel1
ip address 10.154.40.53 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1360
qos pre-classify
keepalive 10 3
tunnel source FastEthernet0/0.1
tunnel destination 10.154.30.1
!
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
!
!
interface FastEthernet0/0.1
description CONNECTION TO CENTRAL
encapsulation dot1Q 2
ip address 10.154.10.53 255.255.255.252
crypto map mymap
!
interface FastEthernet0/1
description INTERNAL LAN
ip address 10.154.34.254 255.255.255.0
duplex auto
speed auto
!
!

!
!
ip route 0.0.0.0 0.0.0.0 Tunnel1
ip route 10.154.10.0 255.255.255.0 Tunnel1
ip route 10.154.30.0 255.255.255.252 10.154.10.54
!
ip access-list extended acl1
permit gre host 10.154.10.53 host 10.154.30.1