Introduction to the VRRP protocol and how it works
1. Introduction to the VRRP protocol
Virtual Router Redundancy Protocol (VRRP) is a protocol designed to increase the availability of the default gateway for hosts on a network. The principle is to define the default gateway for network hosts as a virtual IP address referencing a group of routers.
VRRP is widely used in network architectures where it is essential to maintain constant connectivity even if one of the routers fails. When a router becomes unavailable, VRRP allows another router to immediately take over, without disrupting communications.
VRRP is an IETF [Internet Engineering Task Force, an organization that standardizes Internet protocols] standard supported by many router and firewall manufacturers, as well as operating systems such as Linux. As an open protocol, VRRP is more widely deployed than other similar or proprietary protocols (such as HSRP, which is proprietary to Cisco).
[image 1]
2. How the VRRP protocol works
VRRP operates using a set of routers and utilizes the concept of a virtual router, which is associated with a virtual IP address (VIP) and a virtual MAC address (IP-Tie Breaking). The roles of master router and backup router are used and associated with the routers in a VRRP group.
The master router is associated with the virtual IP address of the group. It is this router that will respond to ARP requests from clients on this IP address (and route network requests).
One or more backup routers can take over the role of master in the event of a failure.
It should be noted that the VRRP protocol operates at layer 3 of the OSI model and therefore does not use the TCP or UDP network protocols. By default, VRRP uses unicast for communication between routers, but it can also use multicast.
a. Operation under nominal conditions
In a nominal situation, the master router is the router with the highest priority (value between 0 and 255). If the priorities are equal, the router with the lowest IP address will be chosen.
Backup routers listen for "HELLO" messages sent (normally every second) by the master router and wait for a potential failure of the latter.
HELLO messages contain the following information: VIP IP address, master router priority, unique VRRP group ID, and the version of the VRRP protocol used.
b. Master router failure
When one or more backup routers no longer receive HELLO packets during the configured period (e.g., 3 seconds), they consider the master router to be offline and therefore inoperative.
A new master router election is launched by VRRP, using the same method as described above (using the router with the highest priority). The latter will therefore retrieve the virtual IP address (VIP) in order to take charge of traffic routing.
When the initial master router comes back online, it can (depending on whether the VRRP group configuration allows it) resume its role if its priority is higher than that of the router that is currently the master.
3. Main differences between versions 2 and 3 of the protocol
| Criterion | VRRPv2 | VRRPv3 |
| Specification | RFC 3768 | RFC 5798 |
| IP address support | IPv4 only | IPv4 and IPv6 |
| Encapsulation | Directly in IP (protocol 112) | Same as above, but with modified package format |
| Authentication | > No authentication > "Plain Text Password" > IP AH (HMAC-MD5-96) | Removed (no built-in authentication) |
| Safety | Weak, easily circumvented | Depends on the security of the underlying network |
| Priority field size | 8 bits | 8 bits (same) |
| Multiple group support | Limited (1 group per interface) | Yes (multiple groups on the same interface) |
[Image2]
VRRP V2 framework
[Image3]
VRRP V3 Frame 1
It should be noted that the main difference between the two versions of the protocol, beyond IPv6 support, is that version 3 of VRRP completely removes any authentication mechanism, assuming that external mechanisms (such as IPSec, VLAN segmentation, ACLs) ensure security.
Keepalived ... and the discovery of a flaw in the RFC
The tool used is Keepalived, a Linux routing software that allows VRRP to be implemented on Linux.
1. Practical case with Keepalived
During these numerous studies and audits, Geoffrey realized that the majority of VRRP environments are not secure, or only minimally so.
In order to set up a model that complies with the recommendations (use of an ID 255 and the highest possible IP on the network on the nominal router, use of unicast mode), he used several Linux machines with Keepalived.
The network was not sufficiently partitioned (user workstations were in the same VLAN as
Once the model was set up, he added a rogue router with the ID 255 and used the rogue router to broadcast VRRP frames, successfully taking control of the network (it became the master router).
Several configurations were tested, and in all cases (even with a pirate router with a lower priority than the master), it became the master of the network.
So the question is: Is this a vulnerability (CVE) in Keepalived?
2. Discovery of a critical vulnerability and correction by an erratum
The bug is not a CVE since Keepalived strictly follows RFC 9568 (defining the VRRP protocol).
Keepalived has nevertheless released a patch to fix the bug, but they claim that they are following the RFC.
Once the doubt was cleared up with the IETF, the RFC was indeed the cause of the malfunction.
Furthermore, the bug is not encountered on Cisco equipment, as it has not yet implemented the latest version of the RFC.
In reality, VRRP packets with a priority of 255 were not actually discarded ("ignored before processing"), which prevented the IP-Tie Breaking mechanisms from functioning and resulted in the router with priority 255 listening to the packets and lowering its priority.
Erratum 8298 was validated by the IETF a few days after its publication by the Keepalived teams.
Conclusion & recommendations
The conference highlighted a serious vulnerability in the VRRP protocol, demonstrated via Keepalived, with a concrete impact: a local attacker can easily spoof the default gateway. Although good network practices (segmentation, filtering, monitoring) reduce this risk, it highlights a conceptual weakness in VRRP that deserves to be taken into account by network engineers.
The following recommendations can be given:
First, when using VRRP V2, use IPSEC authentication (if possible).
As with both VRRP V2 and V3, it is important to configure the protocol in unicast mode in order to prevent network eavesdropping and to be able to rebuild a hijacked VRRP configuration.
You must also adhere to strict VRRP addressing and priority ordering for all routers.
It is also important to segment your network properly to prevent man-in-the-middle attacks.
