Monday, July 8, 2013

VRRP authentication issues ( cisco )

In this post I'm going to show you a interesting  md5 key issues with VRRP

Cisco supports a wide array of protocols that uses  text or md5 based authentication.


All of the above support some types of authentication.

In best common practices,  we want to use the same key-chain key ID for all authentications purporse, but some protocols allows for a slight degree of variance in  the key-chain id for expirations. VRRP is a different beast.Take this snapshot;

And on the  router we have the following key configured;

Notice the BADAUTHs ? Why is this so? Both routers have the keystring of cisclob for their  md5 key ?

Will here's the reason why; " with  VRRP  and authentication, it only supports key-id 0 & with any device using  just a md5 key-string under it's interface.

If you use any other key-id  and no matter if they all match, you will not  acquire authentication between  the VRRP members if one side uses the md5 key-string and the other side just a key-chain.

Once I configured the  key ID to be 0 , or configured both routers  vrrp auth type of "key-chain" , the BADAUTH will go away.

And when using  key-chains only, if the key IDs do not match, you will have problems.

So in this above example, we have a key-chain named vrrp, but the IDs do not match. One side ( r1 ) uses a key id of 1 and the other side a key id of 5.

By updating the key ID on the router#1 to match router#2, VRRP authentication will be established.

So to recap

  1. VRRP authentication and use just a mix of a key-string for our vrrp interface and key-chain, requires the used of a key ID of 0
  2. If you decided to use  key-chain for your vrrp interfaces, all key ID needs to  match.
  3. The highest number key ID in key-chain will be  the key ID used
  4. it probably  best to  not use md5 key-string option at all, under your vrrp interfaces ( imho )
  5. GLBP authentication doesn't exhibit these issues, you either use key-string only or key-chain only thru out your AVG ( no mix and match )

 Ken Felix
Freelance Network/Security Engineer
kfelix ----at---- socpuppets ---d-o-t-- com

    ^       ^
=(  *    *  )
      /      \


  1. Hi Ken,

    Note sure if you have a method to, in case authentication on one router fails, the other router will not become "master" as well. Is this a very poor design, because any rogue device could be configured to join the vrrp group and will mess up the traffic.

  2. Unknown,

    Yes this is a security risk but VRRPv3 has a md5 support for the password under ipv6 and by using "IPSEC-AH" , but how much success you would have would be ???s. ( I have never seen anybody successful execute this btw )

    Since HSRPv2 support both ipv4/6, it would best be served to use HSRPv2 but this is a cisco solution. HSRP v1 or v2 has always had md5 support btw.

    So to answer the question, if the authentication is NOT md5 , anybody could hijack the redundancy protocol operations and selection as primary YMMV on what method you use. I've always try to avoid VRRPv3 or deploy other layer2 security feature from switchport secure mac or arp inspections.