cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2394
Views
0
Helpful
6
Replies

IPSEC and Tunnel Protection

Network Diagram

DR.png

Config of Branch

IOS Version

(C2801-ADVIPSERVICESK9-M), Version 12.4(15)T7,

Physical Interface

interface Vlan220

ip address 10.152.1.202 255.255.255.252

no ip redirects

no ip unreachables

no ip proxy-arp

no ip route-cache cef

no ip route-cache

Tunnel connecting to **

interface Tunnel220

ip address 192.168.220.5 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

ip mtu 1430

ip nhrp authentication dmvpn243

ip nhrp map multicast 10.16.101.1

ip nhrp map 192.168.220.1 10.16.101.1

ip nhrp network-id 243

ip nhrp holdtime 3600

ip nhrp nhs 192.168.220.1

no ip route-cache cef

no ip route-cache

ip tcp adjust-mss 1330

ip ospf network point-to-multipoint

ip ospf cost 10

ip ospf hello-interval 10

ip ospf priority 0

ip ospf mtu-ignore

tunnel source Vlan220

tunnel mode gre multipoint

tunnel key 243

tunnel protection ipsec profile dmvpn-profile

end

Tunnel Connecting to DR

interface Tunnel230

ip address 192.168.230.1 255.255.255.0

no ip redirects

ip mtu 1400

ip nhrp authentication dmvpn230

ip nhrp map 192.168.230.254 10.15.101.1

ip nhrp map multicast 10.15.101.1

ip nhrp network-id 230

ip nhrp holdtime 3600

ip nhrp nhs 192.168.230.254

tunnel source Vlan220

tunnel mode gre multipoint

tunnel key 230

tunnel protection ipsec profile dr

Problem

Show crypto ipsec output ( ommited )

Crypto map tag: Tunnel220-head-0, local addr 10.152.1.202

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (10.152.1.202/255.255.255.255/47/0)

   remote ident (addr/mask/prot/port): (10.15.101.1/255.255.255.255/47/0)

   local  ident (addr/mask/prot/port): (10.152.1.202/255.255.255.255/47/0)

   remote ident (addr/mask/prot/port): (10.16.101.1/255.255.255.255/47/0)

    Crypto map tag: Tunnel230-head-0, local addr 10.152.1.202

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (10.152.1.202/255.255.255.255/47/0)

   remote ident (addr/mask/prot/port): (10.15.101.1/255.255.255.255/47/0)


I am making secure connection to DR ( 10.15.101.1 ) and tunnel comes up however there are some issues with IPSEC . When i remove tunnel protection things start working properly and I can receive ping replies from both ends which means NHRP / DMVPN config is perfect . The issue with IPSEC ( phase 2 ) is that I want to connect 10.15.101.1 ( DR ) and Branch ( 10.152.1.202 ) .

When I check show crypto ipsec sa I can see duplicate proxy identies i.e. 10.152.1.202 - 10.15.101.1 from tunnel 220 ( posted above in quote ) and again in tunnel 230 . To make things work fine it should only appear in Tunnel 230 config .  When I shutdown tunnel 220 the proxy identity goes away from 220 and the only one left is being learned from Tunnel 230 ( the right one ) after that it starts working properly but when both tunnels are up again duplicate entries would come up and i cant ping the other end ( tunnel ) i.e. 192.168.230.x being learned through 10.15.101.1 .

Could this be due to IOS bug ? Note that in above config ( tunnel 220 which points to ** ) I have put ip nhrp map 192.168.220.1 10.16.101.1 which means that in crypto ipsec ( for tunnel 220 ) I should only receive connection to 10.16.101.1 and not 10.15.101.1 .

1 Accepted Solution

Accepted Solutions

Hmmmm, phase 1 DMVPN (which is using point to point on spoke side) doesn't require shared ;-)

It's only multipoint interface problem.

Wll anyway, glad it worked out.

View solution in original post

6 Replies 6

Marcin Latosiewicz
Cisco Employee
Cisco Employee

Since you're sourcing two DMVPN tunnels from same source interface, you should use same IPsec profile and "shared" keyword for this conf to be correct.

Thanks Marcin

If I am having the encryption policies correct then it shoulndt be a problem but considering this a IOS level programing limitation I thought of giving it a try , i used same policy and the result was same .

interface Tunnel220

ip address 192.168.220.5 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

ip mtu 1430

ip nhrp authentication dmvpn243

ip nhrp map multicast 10.16.101.1

ip nhrp map 192.168.220.1 10.16.101.1

ip nhrp network-id 243

ip nhrp holdtime 3600

ip nhrp nhs 192.168.220.1

no ip route-cache cef

no ip route-cache

ip tcp adjust-mss 1330

ip ospf network point-to-multipoint

ip ospf cost 10

ip ospf hello-interval 10

ip ospf priority 0

ip ospf mtu-ignore

tunnel source Vlan220

tunnel mode gre multipoint

tunnel key 243

tunnel protection ipsec profile dmvpn-profile

end

Current configuration : 452 bytes

!

interface Tunnel230

ip address 192.168.230.1 255.255.255.0

no ip redirects

ip mtu 1400

ip nhrp authentication dmvpn230

ip nhrp map 192.168.230.254 10.15.101.1

ip nhrp map multicast 10.15.101.1

ip nhrp network-id 230

ip nhrp holdtime 3600

ip nhrp nhs 192.168.230.254

tunnel source Vlan220

tunnel mode gre multipoint

tunnel key 230

tunnel protection ipsec profile dmvpn-profile

Then I thought it might be reasonable to use that shared keyword rather than dmvpn-profile or else so I even tried that and results were same . I have done the same setup with another customer using 1700 routers ( shared profiles ) and it worked like a charm , dont know why is it showing tunnel 230 proxy identity in tunnel 220 details .

Glad if anyone can provide help .

You are still missing the shared keyword.

http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_dmvpn/configuration/15-2mt/sec-conn-dmvpn-share-ipsec-w-tun-protect.html

What happens later we'll see:

show crypto map

show crypto ipsec sa

show crypto rule

are minimum needed.

Just open a TAC case and have the guys help you out figuring the problem.

Thanks Marcin , works like  a charm

The other customer never had this problem , they were running 1700 , IOS 12.3 running DMVPN Phase 1 with shared ipsec profiles but I never used shared keyword after profile name , maybe something new because of newer code .

Hmmmm, phase 1 DMVPN (which is using point to point on spoke side) doesn't require shared ;-)

It's only multipoint interface problem.

Wll anyway, glad it worked out.

Thanks , with phase 1 I was still using one single physical interface to source 2 tunnels but with that the ipsec algo must be running different way

Thanks a lot