gre over ipsec

[harisapkota123]

Dear all,

I'm trying to establish vpn session between 2 Cisco 892/k9 routers. but when i apply the crypto map in the GRE tunnel interface this type of message apears.

  NOTE: crypto map is configured on tunnel interface.

        Currently only GDOI crypto map is supported on tunnel interface.

As the same crypto map is easily applied to the physical interface instead of GRE, and It works too...  Please verify what causes the problem based on the Debug output and configurations which i have attached with this message.

Any response will be appreciated.

Thank you.

[wzhang]

Hi,

If you are trying to configure GRE over IPSec, then you can do this with one of the 2 configuration options, 1) using crypto map and apply the crypto map to the physical egress interface for the GRE encapsulated tunnel packets, or 2) using ipsec profiles with tunnel protection. With crypto map on the tunnel interface, the order of encapsulation is the opposite of what you are trying to do - it'll be encryption first and then tunnel encapsulation, in other words, it'll be IPSec over GRE. Currently we only support GETVPN with that, hence the warning you saw.

Thanks,

Wen

[caltimirastapia]

Thanks a lot for this answer. I've been looking for this configuration so BAD! I thought my Cisco 881 was useless.

[pthaks_2000]

All,

Thanks for sharing this important information since I am also struggling with the same issue. I receive the same error when I try configuring the crypto-map on tunnel interface without anything on physical interface. However, what confuses me is that I tested this functionality in the lab and it worked absolutely fine without any errors. Following was the configuration:

• GRE tunnel (T1) between spoke site and shared central gateway to access customer vpn routes
  
• GRE tunnel (T2) between spoke site and customer hub site primary CPE with crypto-map configured (this tunnel acted as primary tunnel)
  
• GRE tunnel (T3) between spoke site and customer hub site backup CPE with crypto-map configured (this tunnel acted as backup tunnel)
  

The CPE that I used as spoke site CPE was Cisco 1841 with IOS - c1841-adventerprisek9-mz.124-22.T5.bin.

Now during the acutal customer implementation, we are using Cisco 881 wiht IOS - c880data-universalk9-mz.151-3.T.bin.

Can some one please explain why I did not receive this error during my lab test and what is the easiest way to now resolve this issue.

P.S. Because of customer business critical data, we cannot configure crypto-map on physical interface.

Thanks in advance

Pooja

[Tod Larson]

Are you configuring a Virtual Tunnel Interface with IP Security?

http://www.cisco.com/en/US/technologies/tk583/tk372/technologies_white_paper0900aecd8029d629_ps6635_Products_White_Paper.html

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key ******** address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 10
!
!
crypto ipsec transform-set TSET esp-3des esp-sha-hmac
!
crypto ipsec profile VTI
set transform-set TSET
!
!
interface Tunnel0
ip address 192.168.10.2 255.255.255.0
tunnel source 10.0.149.220
tunnel destination 10.0.149.221
tunnel mode ipsec ipv4
tunnel protection ipsec profile VTI

[pthaks_2000]

Hello Tod,

Not exactly. Please find below the config of Cisco 1841 that I used for  my lab test:

!

!

crypto isakmp policy 10

encr 3des

hash md5

authentication pre-share

crypto isakmp key data address 200.1.1.1

crypto isakmp key data address 90.1.1.1

!

!

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

mode transport

!

crypto map map_Colt 10 ipsec-isakmp

set peer 200.1.1.1

set transform-set trans_Colt

match address 110

!

crypto map map_Colt_1 10 ipsec-isakmp

set peer 90.1.1.1

set transform-set trans_Colt

match address 110

!

archive

log config

  hidekeys

!

!

!

!

!

interface Loopback1

ip address 110.1.1.1 255.255.255.255

!

interface Loopback100

ip address 100.1.1.1 255.255.255.255

!

interface Tunnel1

ip address 150.1.1.1 255.255.255.252

keepalive 5 3

tunnel source 10.1.1.1

tunnel destination 20.1.1.1

!

interface Tunnel2

ip address 160.1.1.1 255.255.255.252

keepalive 5 3

tunnel source 100.1.1.1

tunnel destination 200.1.1.1

crypto map map_Colt

!

interface Tunnel3

ip address 170.1.1.1 255.255.255.252

keepalive 5 3

tunnel source 100.1.1.1

tunnel destination 90.1.1.1

crypto map map_Colt_1

!

interface FastEthernet0/0

no ip address

duplex auto

speed auto

!

interface FastEthernet0/0.1

encapsulation dot1Q 111

ip address 10.1.1.1 255.255.255.252

!

interface FastEthernet0/1

no ip address

shutdown

duplex auto

speed auto

!

router bgp 65505

no synchronization

bgp log-neighbor-changes

redistribute connected route-map red-conn

neighbor 150.1.1.2 remote-as 15404

neighbor 150.1.1.2 next-hop-self

neighbor 150.1.1.2 allowas-in

neighbor 150.1.1.2 soft-reconfiguration inbound

neighbor 150.1.1.2 route-map allow-loop in

neighbor 150.1.1.2 route-map allow-send out

neighbor 160.1.1.2 remote-as 65505

neighbor 160.1.1.2 next-hop-self

neighbor 160.1.1.2 allowas-in

neighbor 160.1.1.2 soft-reconfiguration inbound

neighbor 160.1.1.2 route-map deny-loop-1 in

neighbor 160.1.1.2 route-map allow-only out

neighbor 170.1.1.2 remote-as 65505

neighbor 170.1.1.2 next-hop-self

neighbor 170.1.1.2 allowas-in

neighbor 170.1.1.2 soft-reconfiguration inbound

neighbor 170.1.1.2 route-map deny-loop in

neighbor 170.1.1.2 route-map allow-only out

no auto-summary

!

ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 10.1.1.2

no ip http server

no ip http secure-server

!

!

!

access-list 1 permit 100.1.1.1

access-list 1 permit 110.1.1.1

access-list 2 permit 90.1.1.1

access-list 2 permit 100.1.1.1

access-list 2 permit 200.1.1.1

access-list 2 permit 10.1.1.0 0.0.0.3

access-list 2 permit 20.1.1.0 0.0.0.3

access-list 3 permit 90.1.1.1

access-list 3 permit 200.1.1.1

access-list 4 permit 100.1.1.1

access-list 5 permit 110.1.1.1

access-list 110 permit ip host 110.1.1.1 host 210.1.1.1

!

!

!

!

route-map deny-loop deny 10

match ip address 2

!

route-map deny-loop permit 20

!

route-map deny-loop-1 deny 10

match ip address 2

!

route-map deny-loop-1 permit 20

set weight 500

!

route-map allow-only permit 10

match ip address 5

!

route-map allow-loop permit 10

match ip address 3

!

route-map allow-send permit 10

match ip address 4

!

route-map red-conn permit 10

match ip address 1

!

eBGP was the routing protocol that I used and the route-maps were used to filter the routes.

[Richard Burts]

I do not see how this configuration could have worked in testing. My experience is that fairly old versions of IOS would allow the crypto map to be configured on the tunnel interface. But anything nearly as recent as 12.4T will not do crypto map on the tunnel for a GRE/IPSec tunnel.

If there are reasons why you can not put a crypto map on the physical interface then I agree with the original suggestion by Wen and suggested again by Tod that you use the tunnel protection profile which will allow the tunnel to do GRE protected by IPSec and does not require crypto map.

HTH

Rick

[pthaks_2000]

Thanks Richard but still confusing for me because this configuration did work during the testing; I did not get any error while configuring crypto-map on tunnel without configuring it on physical interface.

Having said that, as you suggest that we do the tunnel protection profile method here.

What I also wanted to understand is can GetVPN concept be used here to achieve this?

Thanks

Pooja

[wzhang]

Hi,

This crypto map check on the tunnel interface was only added in IOS 15.1(2)T and later, and that's probably why you didn't see if during your testing with an older version of IOS.

For GRE over IPSec implementations, yes we do recommend customer to use Tunnel protection instead of crypto maps.

As far as GETVPN goes, it uses a completely different security paradigm. For starters, there is no more pair-wise tunnels with GETVPN. So you probably want to look into it to see if that actually meets your deployment requirement. I would recommend you take a look at the GETVPN Design and Implementation Guide to get more info on that:

http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6525/ps9370/ps7180/GETVPN_DIG_version_1_0_External.pdf

Thanks,

Wen

[Richard Burts]

Thank you Wen. This clarification is very helpful.

HTH

Rick

[Gerardo Marciales]

Tod, I followed your indications, and work perfectly, thank you!

[Taheireem Shaikh]

thanks a lot for the ans....