ā05-12-2011
03:56 AM
- last edited on
ā02-21-2020
11:50 PM
by
cc_security_adm
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.
ā05-16-2011 07:14 PM
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
ā12-15-2011 05:57 AM
Thanks a lot for this answer. I've been looking for this configuration so BAD! I thought my Cisco 881 was useless.
ā02-15-2012 05:07 AM
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:
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
ā02-15-2012 05:40 AM
Are you configuring a Virtual Tunnel Interface with IP Security?
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
ā02-15-2012 08:09 PM
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.
ā02-15-2012 08:59 PM
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
ā02-16-2012 01:13 AM
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
ā02-16-2012 08:47 AM
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:
Thanks,
Wen
ā02-16-2012 09:13 AM
Thank you Wen. This clarification is very helpful.
HTH
Rick
ā09-07-2013 07:48 PM
Tod, I followed your indications, and work perfectly, thank you!
ā09-02-2015 03:30 AM
thanks a lot for the ans....
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide