GETVPN KS placement

rtjensen4 · ‎07-03-2012

Where's the ideal place to put the KS?

My current setup is 1 KS, 19 GM. The KS sits BEHIND a GM, so all other GMs have to come through one GM to get to KS.

Now, I have purchased two dedicated KS routers. I configured one today, and placed it right on my WAN. My WAN is a L2 Ethernet domain, so i just provisioned a switch port in the WAN vlan, and away we go. I copied RSA keys over from the current KS, configured redundancy and the two hooked up, saw each other and it seems to be good to go. For the ACL, I put in an exclustion for my two KS to talk to each other:

deny ip host 192.168.250.40 host 192.168.250.41 (Old IP, New IP)

deny ip host 192.168.250.41 host 192.168.250.40.

I used a test router and pointed it to the new KS, it registered without a hitch... HOWEVER about two hours later (my 7200 second timeout) I lost ALL my branches. My 18 other GM were still pointed to the OLD IP only, they didnt have the second IP configured yet. In a hurry, I quickly disabled the redundancy configuration on the old KS and had to go to each GM and do a 'clear crypto gdoi' on each one to get them to re-register. There were no log messages about not being able to rekey, no log messages about dropped peerings, nothing. Once I did that, everything returned to normal. Note: NOTHING else changed other than the things I noted above. Had I more time and all my branches weren't down, I probably would have tried clearing manually FIRST, but I didnt have that opportunity. I just removed anythign i had changed in an effort to get back to normal.

The Question I have...

Would having configured the redundant KS caused this problem? Would having one KS behind a GM and the other Coop KS in the WAN make a difference? ANy thoughts on WHY I experienced the above behavior?

Relevant config from existing KS, 2801:

crypto gdoi group GETVPN_GROUP

identity number 1234

server local

rekey retransmit 60 number 2

rekey authentication mypubkey rsa GETVPN_KEYS

rekey transport unicast

sa ipsec 1

profile GETVPN_PROFILE

match address ipv4 getvpn-encrypt

replay time window-size 5

address ipv4 192.168.250.40

crypto ipsec profile GETVPN_PROFILE

set security-association lifetime seconds 7200

set transform-set GROW

crypto ipsec transform-set GROW esp-aes 256 esp-sha-hmac

sh access-list getvpn-encrypt

Extended IP access list getvpn-encrypt

10 deny eigrp any any

20 deny udp any eq isakmp any eq isakmp

30 deny udp any any eq 848

40 deny tcp any any eq 22

50 deny tcp any eq 22 any

60 deny tcp any any eq tacacs

70 deny tcp any eq tacacs any

80 deny esp any any

90 deny pim any any

100 deny ip host 192.168.250.40 host 192.168.250.41

110 deny ip host 192.168.250.41 host 192.168.250.40

120 permit ip any any

The NEW KS is a 2901, config is VERY basic, a WAN IP, a loop back, basic EIGRP info and the same GDOI info as above.

Marcin Latosiewicz · ‎07-03-2012

I think the problem might have been the election of who is the master in COOP cluster - typically when introducing any new device we make sure it will not be the one to send rekeys.

In this case the most PROBABLE explanation is the new KS became the one to send rekeys and didn't have information about GMs to send that info to.

It would be great to have more outputs to confirm but I understand you were acting under time constraints.

Rule of thumb - you should make sure that path to KS is OOB path from perspective of GDOI - not crossing anything - although in this particular case it might not have been THE problem.

rtjensen4 · ‎07-05-2012

Ok, thanks for the info. Yeah, I'm not sure if that's what happened or not. I made sure that the existing KS had a priority of 200 and the new one had a priority of 150, theoretically, the old one should've been the only one to give keys. Besides, none of the GM even knew about the new KS. So, if i understand your rule of thumb, It's a good thing I'm putting the new KS right on the WAN? so the GMs can talk right to it without going through any other GMs.