Re: basic GRE-ipsec questions

Rik19972000 · ‎08-16-2009

I'm new to GRE tunnels and I've some quick questions

1)tunnel at one side stays up, unless the source interface defined under tunnel goes down?

2)if marking(L3) is done at the edge there's no need for qos preclassify

3)in a IPsec over GRE hub and spoke topology: gre multipoint needs only to be configured on the hub? I've seen that for DMVPN needs to be configured on the spokes but I suppose this is because they can dynamically setup tunnels with other spokes?

4) when is cryptomap profile used and when crypto-map?

Peter Paluch · ‎08-16-2009

Hello Rik,

1.) A Tunnel interface stays up if all these conditions are met:

i) The "tunnel source" interface is up/up

ii) The "tunnel destination" address is reachable according to your routing table

iii) If the GRE Keepalives are used, your router must be receiving the keepalives

2.) Not exactly. The reason for using qos pre-classify is that when a packet is transmitted out an interface with a crypto map, it is already GRE-encapsulated and/or encrypted before the QoS policies are applied. If you are classifying your packets using deeper inspection (transport protocol, ports, ...) on the outbound interface, this classification would not work here because the packet is already tunelled or even encrypted and thus the headers you are looking for are not visible anymore. The qos pre-classify feature allows you to make an internal copy of the original header prior encapsulation or encryption and automatically use them for classifying the packet on the outbound interface.

I suggest studying this wonderful document:

http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800b3d15.shtml

3.) The GRE multipoint interface must be configured on all routers in a DMVPN, both hub and spokes. The goal of the DMVPN is to allow a direct communication of any pair of routers that are part of the DMVPN, so it applies to hub as well as to spokes. When the DMVPN "boots up", the spokes register to the hub and hub should be able to contact the spokes over the single Tunnel interface, hence the need for a multipoint interface on the hub. Further, when two spokes want to talk to each other, they ask the hub to provide the real (i.e. the NBMA) IP address and then they will set up a dynamic tunnel to each other, again using that same Tunnel interface, hence the need for multipoint tunnel interfaces on spokes.

4.) The main difference between the crypto profile and crypto map is that the crypto profile is intended to be used only on Tunnel interfaces and it does not support the "match address" and "set peer" options. The crypto profile does not need them because the peer is effectively defined with the "tunnel destination" command and the traffic to be encrypted is all the traffic that passes through the tunnel interface.

The crypto profile is simply a different way of providing the IPsec protection for tunnel interfaces. If using GRE over IPsec, a crypto map applied on the outbound interface will see the GRE encapsulated packets, therefore, the ACL used in the crypto map must match the GRE protocol with the IP addresses of tunnel source and tunnel destination as the source and destination IP of the GRE-encapsulated packets. On the other hand, the crypto profile applied on the Tunnel interface will see the original IP header of the traffic to be encapsulated and encrypted.

Also, the crypto profile effectively allows you to create a pure IPsec tunnel (without the GRE encapsulation) that is represented by a Tunnel interface. Without a crypto profile, this is not possible, as the IPsec tunnel was originally created only with a crypto map that did not by itself constitute an interface.

So to summarize this, the crypto profile is used only on Tunnel interfaces to provide IPsec protection for the traffic passing through that Tunnel. The protection is turned on the Tunnel interface using the command tunnel protection ipsec profile PROFILE_NAME. The crypto map can be used on any interface and it uses ACLs and "set peer" commands to define which traffic should be encrypted and where should it be sent.

Please ask further if there is anything unclear.

Best regards,

Peter

Rik19972000 · ‎08-16-2009

Thanks Peter,

about 2) I assume that classification has been done at the access layer. I know that IPsec copies the ToS byte to the outher header(tunnel mode). But before it's first GRE encapsulated. I'm unsure if GRE copies the ToS byte to the outher header.

3) I know it has to be done with DMVPN because the spokes can dynamically setup tunnels with other spokes. My question is if you've to configure the spokes as multipoint in a Hub and spoke scenario where the spokes can't speak with each other. (no DMVPN thus)

I've setup DMVPN in GNS3 with 1 hub, 2 spokes and an "ISP". And EIGRP via tunnel IP. It was constantly flapping. I suppose it is due to split horizon (As the tunnel IP address range is shared among hub and spokes). I wanted to test with no split-horizon eigrp x under the tunnel interface but I hadn't yet the chance to test as GNS3 constantly crashed :D

Peter Paluch · ‎08-16-2009

Hello Rik,

About 2): I believe that also if doing a pure GRE tunnel, the inner DSCP value is copied to the outer IP header.

About 3): You have raised an interesting question. I have not tried configuring this yet. I will have to give it a try. About that flapping: what exactly was flapping? The EIGRP or the tunnels themselves?

Best regards,

Peter

Giuseppe Larosa · ‎08-16-2009

Hello Rik, Peter

2) yes GRE header DSCP is a copy of inner DSCP of carried packet and in an GRE over IPSec scenario this means the IPSec external ip header is a copy of that of carried packet inside the GRE.

We have used this for a remote site connected with an ADSL link with a 871 and worked.

3) with DMVPN when using EIGRP:

no ip eigrp split-horizon is needed on hub unless hub sends a default route to spokes.

for making dynamic spoke to spoke possible an additional command is needed:

no ip eigrp x nexthop-self with no summarization to have one spoke to see remote lan ip subnet with the next hop of the other spoke

Hope to help

Giuseppe

Peter Paluch · ‎08-16-2009

Hey Giuseppe,

Thank you for your answer! Regarding the third question, yes, if using EIGRP for routing in the DMVPN, both the command no ip split-horizon eigrp and no ip next-hop-self eigrp.

I did not want to discuss these commands sooner, as Rik has mentioned a problem with "flapping". However, it was not clear what has flapped, so I didn't want to talk about commands yet that would not contribute to solving that "flapping".

Best regards,

Peter

Rik19972000 · ‎08-17-2009

thx,

at the moment I'm trying to setup a hub-spoke scenario without that the spokes can speak to each other without GRE

the spokes have a dynamic IP

I followed this guide:

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080093f86.shtml

in the doc

dr_whoovie:

has in my setup:

lo 23 100.0.0.5 255.0.0.0 (simulation users subnet)

ser0/0: 2.2.2.1

SAM-I-AM

lo5: 5.5.5.5/32

ser0/0 1.1.1.1

setup

Lo5 --HUB-ser0/0 (1.1.1.1)# <--> #1.1.1.2(ser0/0)ISP---ser0/1(2.2.2.2)# <---->#2.2.2.-ser0/0-SPOKE

static route : 0.0.0.0 0.0.0.0 ser0/0 on HUB and SPOKE

I can ping ser0/0 from/to HUB --SPOKE

but when I built this scenario and apply crypto map etc. I can't ping anything anymore.

config:

HUB

---------------------------------------

hostname HUB

!

boot-start-marker

boot-end-marker

!

memory-size iomem 10

no aaa new-model

ip subnet-zero

ip cef

!

crypto isakmp policy 5

encr 3des

authentication pre-share

group 2

crypto isakmp key KEY address 0.0.0.0 0.0.0.0

!

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

!

crypto dynamic-map DYN_MAP_TEMPL 5

set transform-set ts1

!

crypto map DYNAMIC 5 ipsec-isakmp dynamic DYN_MAP_TEMPL

!

interface FastEthernet0/0

no ip address

shutdown

duplex auto

speed auto

!

interface Serial0/0

ip address 1.1.1.1 255.0.0.0

crypto map DYNAMIC

!

interface FastEthernet0/1

no ip address

shutdown

duplex auto

speed auto

!

interface Serial0/1

no ip address

shutdown

!

ip http server

no ip http secure-server

ip classless

!

access-list 100 permit ip host 5.5.5.5 100.0.0.0 0.0.0.255

-------------------------------------

hostname SPOKE

!

boot-start-marker

boot-end-marker

!

memory-size iomem 10

no aaa new-model

ip subnet-zero

ip cef

!

crypto isakmp policy 5

encr 3des

authentication pre-share

group 2

crypto isakmp key KEY address 1.1.1.1

!

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

!

crypto map STATIC 5 ipsec-isakmp

set peer 1.1.1.1

set transform-set ts1

match address 100

!

interface Loopback23

ip address 100.0.0.5 255.0.0.0

!

interface FastEthernet0/0

no ip address

shutdown

duplex auto

speed auto

!

interface Serial0/0

ip address 2.2.2.1 255.0.0.0

crypto map STATIC

!

interface FastEthernet0/1

no ip address

shutdown

duplex auto

speed auto

!

interface Serial0/1

no ip address

shutdown

!

ip http server

no ip http secure-server

ip classless

ip route 0.0.0.0 0.0.0.0 Serial0/0

!

access-list 100 permit ip 100.0.0.0 0.0.0.255 host 5.5.5.5

----------------------------------

config ISP

interface Serial0/0

ip address 1.1.1.2 255.0.0.0

!

interface FastEthernet0/1

no ip address

shutdown

duplex auto

speed auto

!

interface Serial0/1

ip address 2.2.2.2 255.0.0.0

!

-------------------------------------

OUTPUT

SPOKE#ping 1.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

I thougt it would traverse the link without being encrypted as its not matched as interesting traffic

Rik19972000 · ‎08-17-2009

part 2: output when pinging 5.5.5.5 via loo 23=> see attachment + debug crypto output

I found for MN_NO_STA that I've to check phase 1 policies but they are the same!

++++++++++++++++++++

I want to simulate a scenario of 2 remote sites with dynamic IP to a HQ. That's why I used the crypto isakmp key TEST add 0.0.0.0 0.0.0.0

=> without GRE

In the setup there is no dynamic IP but it's not known at the hub, thus it's more or less the same

Peter Paluch · ‎08-17-2009

Rik,

Perhaps I am missing something or the config displayed here is not complete but your HUB router seems to be missing the default route. Is that so?

Best regards,

Peter

Rik19972000 · ‎08-17-2009

you're right,

but it has been in place. I'll check it on some real devices today.

But I think that could be the reason. Because when I did the ping it reached the other side > ISAKMP debug on the other side. But it had no return route.

Stupid :)

Rik19972000 · ‎08-18-2009

indeed, that was the problem.

A new challenge.

I converted the config above to a crypto profile in conjunction with tunnel (tunnel mode ipsec) as Peter explained.

at SPOKE:

interface Tunnel10

ip address 192.168.1.1 255.255.255.0

tunnel source FastEthernet0/0

tunnel destination 1.1.1.1

tunnel mode ipsec ipv4

tunnel protection ipsec profile SECprofile

on HUB:

interface Tunnel10

ip address 192.168.1.1 255.255.255.0

tunnel source FastEthernet0/0

tunnel mode ipsec ipv4

tunnel protection ipsec profile SECprofile

If I define a tunnel destination on the hub, the tunnel comes up. If not, the tunnel stays in up/down

Is it possible without dyndns or something like this

Peter Paluch · ‎08-18-2009

Hello,

You are trying to create a multipoint IPsec interface on the HUB, aren't you? I am not sure if this would work because an IPsec tunnel interface is point-to-point in nature. You would need to run the usual DMVPN combination of GRE+NHRP+IPsec here to have the multipoint interface which is IPsec protected.

There is a possibility of so-called DVTI (Dynamic Virtual Tunnel Interfaces) but the document that describes them states that they can only be used within the context of Easy VPN and they are not supposed nor supported to be used by routing protocols. Also, a static VTI cannot, according to that document, terminate at the DVTI. For more information, see

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6635/prod_white_paper0900aecd803645b5.html

Best regards,

Peter

Rik19972000 · ‎08-18-2009

Thanks peter,

I also came to the same conclusion. It worked with GRE but the mode was GRE multipoint.

Thanks for helping!