GETVPN Questions

[Patrick McHenry]

Hi -

I'm going to implement GETVPN on our network. I've just started labbing it in GNS and got it working but I have a couple of questions.

When would it be neccessary (how may routers in network) to use multicasting for distributing the keys?

It's best practice to have more than one key server. To have key servers to also act as GMs you would need to configure 2 groups, correct?

That way, the key servers can join the group that they are not the key server of.

Is it possible for a GM to be a member of more than one group or at least be configured to have a backup group so, if it's key server were to go down, it could join the other group that still has a functioning key server?

Thank you

[Richard Burts]

I have an answer for at least one of your questions. I have worked with GETVPN for a customer in which some of the routers were members of two groups. It worked fine. I created a second ISAKMP policy (we were changing encryption levels), a second gdoi group, and a second crypto map. We assigned the original crypto map on one interface and the new crypto map on a different interface and it worked. On the key servers we just created matching ISAKMP policy and crypto policy. So the same key servers managed both groups and it worked well for us.

If your reason for having two groups is just a way to get redundancy for key server then you are making it way too complex. Just configure the two key servers as cooperative in the same group and you get redundancy with no need for a second group (and no requirement for a second interface to be active in GETVPN on the group members. We did two groups as a transition mechanism and it worked well for that. But it is way more work than it is worth just to get redundancy.

We had two key servers for redundancy and they functioned only as key servers. We separated the functions of key server and group member so I can not address the implications of trying to do both key server and group member on the same router. As the network gets much size I would think it would be possible to justify separate devices as key server and as group member.

HTH

Rick

[Patrick McHenry]

Thanks Rick

I guess I was making it complex because I was trying to figure out a way to make the key server also be a member of a group. From what I understand a router cannot be a key server for a group and also a memeber of that same group.

I would like to deploy this GETVPN solution without purchasing additional routers if possible. Do you think we could use our voice gateways as key servers?

Thank you

[Richard Burts]

If you have two key servers then just configure them as cooperative. I think it is way more complicated than it is worth trying to create two groups just to achieve redundancy for key servers. And as I think about it the requirement that group members have two interfaces participating in GETVPN would probably be more than you were planning for with group members.

Assuming that your voice gateways are running code that supports it, and assuming that there is good connectivity between your voice gateways and the parts of the network where GETVPN will be running then I think it should be quite possible to use your voice gateways as your key servers.

HTH

Rick

[Patrick McHenry]

Thanks Rick,

Yes, I agree it would be unnessessarily complicating the network. I'm going to look into making our voice gateways key servers - if it's not possible I guess we will have to buy some more routers.

Thank you

[elambletcosta]

I Need Help for Questions

I had a problem with my key servers in GETVPN, I could not understand well so far. My two key servers had problems with being a key issue of inspiration and had other physical problems. I have configured the OPEN and CLOSED in my understanding communication between GM should continue with the same problem with key servers, but went more than 24 hours and ended up falling all GETVPN network. My question is as follows: after the fall of the keys, primary and secondary servers in more than 24 hours while the TEK keys no longer work and the whole network goes down and it even?

[Richard Burts]

I do not really understand your description of your problem. But based on what I think I understand here is what I would answer. The Traffic Encryption Key has a limited lifetime. As you get close to the expiration of the key the Group Member attempts to communicate with the key server to get the new information. If neither key server is able to respond to the Group Member then when the Traffic Encryption Key expires and the existing Security Associations can not be re-negotiated then the Group Member can no longer encrypt traffic or decrypt traffic. This is why we frequently advise to have a secondary/cooperative key server.

HTH

Rick

[elambletcosta]

Rick,

Thank you for your attention.
In this case I have two key servers, however both failed! The first had trouble certificate expiration and secondary physical problems presented. My question and the communication between the GM would be kept and for how long?

[Richard Burts]

As long as the Group Member has a valid Security Association (SA) it will be able to encrypt/decrypt traffic using the Traffic Encryption Key. As it approaches the end of the SA it will attempt to negotiate for a new SA and a new key. It will attempt to negotiate with the primary server and then with the backup server. If negotiation with both servers fails then there is no new key and when the SA/TEK expire then the router can no longer encrypt/decrypt traffic. How long the key is valid for is dependent on the lifetime that you configured on the key servers.

This is pretty much what I attempt to explain before but from a somewhat different perspective. I hope this is helpful.

HTH

Rick

[elambletcosta]

Rick,

Thanks for your attention and sorry for bad english.
But what would happen if communication with the server primary and backup failed?  With this scenario  the entire network stay without communication?

Thanks.

[Richard Burts]

If communication with all key servers fails for an extended period then it is likely that the Security Assocations will time out and expire and the TEK will also expire. If new SA can not be negotiated there will be no new TEK and the router will not be able to encrypt traffic. That does not necessarily mean no communication. But what communication does take place would not be encrypted.

HTH

Rick

[wpalumbo06]

Hello all,

I realize that this is an old thread but wanted to post a recent GetVPN outage that I encountered just in case others are reading this.  This thread almost touches on my issue but not quite.  If you run COOP Key Servers, MAKE SURE YOU ENGINEER THE CONNECTIVITY BETWEEN THEM WITH REDUNDANCY!.  In my particular scenario the outage was probably a rare condition but it did highlight an important aspect of GetVPN.  In short, we experienced a routing problem in one of our Data Centers that left the Key Servers unable to communicate with each other but they were both able to communicate with the Group Members.  This resulted in both key Servers assuming the primary role and they began generating their own keys.  When the TEK expired on the GMs, the network started to fail as some GMs got different TEKs.  Bottom line is make sure you understand the criticality of the COOP KS communications and the chaos that will envelope your network if the COOP Key Servers lose their ability to communicate with each other.  If you see the below log message on the secondary KS, you might want to get ready for the storm...

Mar  6 03:00:47.519: %GDOI-5-COOP_KS_TRANS_TO_PRI: KS 10.150.0.6 in group GDOI transitioned to Primary (Previous Primary = 10.150.0.2)

[paul driver]

Hello

I have recently been studying GETVPN - not had the change to lab it up yet but maybe I can shed some information mostly plagiarised from my study material

When would it be necessary (how may routers in network) to use multicasting for distributing the keys? - I am on the understanding here that its advisable to use MC for rekeying ONLY if you whole network is MC capable but if most GM's are unicast or only a small portion of your network is unicast then use unicast advisable.

And the difference between the two rekeying methods are:
MC- retransmits the key several times
UC - require rekey acknowledgment thus incurring more overhead


To have key servers to also act as GMs you would need to configure 2 groups, correct? - Not sure if a key server can also be a GM for another group?????
 

Is it possible for a GM to be a member of more than one group or at least be configured to have a backup group so, if it's key server were to go down, it could join the other group that still has a functioning key server? - The GM's register to ONLY one key server

However GETVPN can have up to 8 multiple KEY servers  on the network- (cooperative key servers) running in a Primary/Secondary scenario using COOP (cooperative key server protocol)

The primary key server creates  IPsec session keys and pushes them to its secondarys key servers which in turn distributes these session keys to the GM's.

The GM's register to ONLY one key server and rekeying is sent by the primary key server ONLY

I am on the understanding that the cooperative server synchronise with each other and this is where the GM's get the resiliency from.

Benefits of multiple Key servers:
Allows a GM router to register to the closet key server
Allows for key server resiliency

res

Paul