08-01-2011 12:31 AM
Hello
I am trying to setup a GETVPN network. The idea is to encrypt all GRE traffic between peers (for DMVPN use). Also, there can be no dedicated KSs (no extra routers that can handle this).
The VPN is brought up successfully with only one KS. However, when redundancy is configured, a few minutes into testing the configuration, I see this:
Aug 1 07:13:52.643: %GDOI-3-COOP_KS_UNREACH: Cooperative KS 10.10.10.6 Unreachable in group GETVPN. IKE SA Status = Failed to establish.
Aug 1 07:14:12.643: %GDOI-3-COOP_KS_UNREACH: Cooperative KS 10.10.10.6 Unreachable in group GETVPN. IKE SA Status = Failed to establish.
Where 10.10.10.6 is the "secondary" KS.
What I did was this:
- 4 routers, all members of the same group; full IP connectivity between their WAN-side addresses (10.10.10.x), no access-lists for traffic filtering
- one "main" KS, where I generated the GETVPN keys and first setup the whole network
- two "secondary" KSs, to allow for redundancy in case one of the KSs goes down (remaining KS could not register to the getvpn otherwise)
Shortly after configuring everything, it works. Doing "clear crypto sess" also gets things back ontrack. However the solution is not stable. Apparently related to rekeys.
CENTRAL ROUTER CONFIG ("main" KS):
hostname CENTRAL
!
no aaa new-model
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
lifetime 3600
!
crypto isakmp key SECURIZARE-PSK address 10.10.0.0 255.255.0.0
crypto isakmp keepalive 10 periodic
!
crypto ipsec transform-set TS-GETVPN esp-3des esp-md5-hmac
!
crypto ipsec profile VPNprofile
set transform-set TS-GETVPN
!
crypto gdoi group GETVPN
identity number 747
server local
rekey lifetime seconds 2500
rekey retransmit 30 number 3
rekey authentication mypubkey rsa GETVPN_KEYS
rekey transport unicast
sa ipsec 1
profile VPNprofile
match address ipv4 DM_GET_VPN_CRYPTO_POLICY
replay time window-size 5
address ipv4 10.10.10.2
redundancy
local priority 110
peer address ipv4 10.10.10.6
peer address ipv4 10.10.10.34
!
crypto gdoi group GETVPN-MEMBER
identity number 747
server address ipv4 10.10.10.6
!
crypto map CMAP-GETVPN local-address FastEthernet0/0
crypto map CMAP-GETVPN 10 gdoi
set group GETVPN-MEMBER
!
interface Tunnel100
!
interface Tunnel200
!
interface Tunnel300
!
interface FastEthernet0/0
ip address 10.10.10.2 255.255.255.252
duplex auto
speed auto
crypto map CMAP-GETVPN
!
interface FastEthernet0/1
!
router eigrp 64
!
ip forward-protocol nd
ip route 10.10.0.0 255.255.0.0 10.10.10.1
!
ip access-list standard DM_GET_VPN_PEER_LIST
permit 10.10.10.2
permit 10.10.10.6
permit 10.10.10.16
permit 10.10.10.32
!
ip access-list extended DM_GET_VPN_CRYPTO_POLICY
deny udp any eq 848 any eq 848
permit gre any any
!
ntp master 10
end
SECONDARY ROUTER CONFIG (two of them, identical configs except IPs adn Hostname, both split from CENTRAL KS server)
hostname DRCnr1
!
no aaa new-model
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
lifetime 3600
!
crypto isakmp key SECURIZARE-PSK address 10.10.0.0 255.255.0.0
crypto isakmp keepalive 10 periodic
!
crypto ipsec transform-set TS-GETVPN esp-3des esp-md5-hmac
!
crypto ipsec profile VPNprofile
set transform-set TS-GETVPN
!
crypto gdoi group GETVPN
identity number 747
server local
rekey lifetime seconds 2500
rekey retransmit 30 number 3
rekey authentication mypubkey rsa GETVPN_KEYS
rekey transport unicast
sa ipsec 1
profile VPNprofile
match address ipv4 DM_GET_VPN_CRYPTO_POLICY
replay time window-size 5
address ipv4 10.10.10.6
redundancy
local priority 100
peer address ipv4 10.10.10.2
peer address ipv4 10.10.10.34
!
crypto gdoi group GETVPN-MEMBER
identity number 747
server address ipv4 10.10.10.2
!
crypto map CMAP-GETVPN local-address FastEthernet0/0
crypto map CMAP-GETVPN 10 gdoi
set group GETVPN-MEMBER
!
interface Tunnel100
!
interface Tunnel200
!
interface Tunnel300
!
interface FastEthernet0/0
ip address 10.10.10.6 255.255.255.252
duplex auto
speed auto
crypto map CMAP-GETVPN
!
interface FastEthernet0/1
!
router eigrp 64
!
ip forward-protocol nd
ip route 10.10.0.0 255.255.0.0 10.10.10.5
!
!
!
ip access-list standard DM_GET_VPN_PEER_LIST
permit 10.10.10.2
permit 10.10.10.6
permit 10.10.10.16
permit 10.10.10.32
!
ip access-list extended DM_GET_VPN_CRYPTO_POLICY
deny udp any eq 848 any eq 848
permit gre any any
ip access-list extended ESP
permit esp any any
!
ntp server 10.10.10.2
end
The other KS config is identical, except for the IP (10.10.10.34 instead of 10.10.10.6). Also, physically removing the third KS from the configuration (turn off router, remove relevnt config lines from other KS routers) does not impact the problem (i.e. the exact same thing happens).
All routers are running 12.4(24)T5.
Any assistance in solving this problem is greatly appreciated. I've been trying everything and still can't make the KS COOP stable for more than a few mintues. Maybe I missed something obvious...
08-01-2011 06:26 AM
There has to be dedicated KS(s) in a GETVPN domain. One has to be primary. GM can split the registration among multiple key servers in the domain, but only the primary key server will perform the rekey. KS can not be GM simultaneously (KS can not encrypt with PHASE II keys). It is recommended that the Key Servers be placed in an ethernet segment where they will not be the next next hop for any throughput traffic. GMs need to be able to route to the KS, not through it.
The crypto maps applied to the interfaces on the KS need to be removed and verify that RSA keys with label
GETVPN_KEYS have been generated on all KS.
HTH.
Dan
08-01-2011 06:34 AM
Thanks for the reply, however it doesn't help me.
I've read in a few places about KSs and GMs coexisting by using different GDOI groups. That's what I'm trying to do.
Three KSs with a GETVPN-SERVER gdoi group, each of which with a GETVPN-MEMBER gdoi group that aptempts to register to the other two servers. That way, I have a set of 3 KSs with redundancy against any single device failure. Note that no single device tries to register to itself - that is noted as impossible by the documentation.
The remaining (30 or so) members can register to either of the three KSs (doesn't matter).
What I am aiming for is redundancy without the overhead of two dedicated KSs. It should be possible and according to everyhing I read, the above config should work. Yet it does not.
08-31-2018 12:29 PM
did you make it ?
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