Description

The use of protocol vrrp in the Loopback filter will not work, when VRRP is configured with MD5 authentication. What is required to match a VRRP packet with MD5 authentication?

Symptoms

VRRP packets are sent on the 224.0.0.18 Multicast address and 112 IP protocol number.

From the packet capture, the fields are as follows:

length 60: (tos 0xc0, ttl 255, id 67, offset 0, flags [none], proto: VRRP (112), length: 40) 60.60.60.4 > 224.0.0.18: VRRPv2-advertisement 20: vrid=10 prio=254 authtype=none intvl=1 addrs: 60.60.60.1
When VRRP is configured with the MD5 authentication, it uses the Authentication Header; which uses the 51 IP protocol number.
user@router# show interfaces
ge-3/1/0 {
    unit 0 {
        family inet {
            address 60.60.60.4/24 {
                vrrp-group 10 {
                    virtual-address 60.60.60.1;
                    priority 100;
                    authentication-type md5;
                    authentication-key "$ABC123"; ## SECRET-DATA
                }
            }
        }
    }
}

From the packet capture, the fields with AH are as follows:
tos 0xc0, ttl 255, id 9753, offset 0, flags [none], proto: AH (51), length: 64) 60.60.60.2 > 224.0.0.18: AH(spi=2880154539,sumlen=16,seq=0x125f2): VRRPv2-advertisement 20: vrid=10 prio=200 authtype=ah intvl=1 addrs: 60.60.60.1
If you configure a loopback filter to match the VRRP packet by using the generally used method ( protocol vrrp ) in a filter, it will then look for the packets with the 112 IP protocol number; but the VRRP packets with MD5 arrive on the 51 IP protocol number. So, the loopback filter will not match the VRRP packet, which causes unexpected behavior in the network.

Solution

To match a VRRP packet with MD5 authentication, add the following term parameters. For example:

user@router# show firewall
filter vrrp {
    term vrrp {
        from {
            destination-address {
                224.0.0.18/32;
            }
        protocol [ vrrp ah ];    
        }
        then accept;
    }
}


The "protocol [ vrrp ah ]"  is a logical OR operation. Only one of the protocols in the list needs to match in order for "protocol" to be evaluated as true.

For more details on setting a Solid loopback filter, please check: Securing the Routing Engine on M, MX, and T Series

Modification History

2024-08-19: Removed E-series from product category as it is EOS
2022-10-03: Highlighted output keywords in blue, added more specific matching condition and added the link for Securing routing engine Document.
2020-02-26: minor non-technical edits.
 

Related Information

Securing the Routing Engine on M, MX, and T Series