Aruba & ProVision-based

Access Control Lists for Restricting VRRP Traffic

 
JohnLockie
Occasional Advisor

Access Control Lists for Restricting VRRP Traffic

Supposing I wanted to prevent anyone from hearing our VRRP traffic or sending their own VRRP messages to our switches, would the following work?

 

Assume I have 2 switches configured for VRRP on VLAN 5, and they are each 1.1.1.1 and 1.1.1.2.  The following commands are placed on switch 1.1.1.1, with the same commands basically done on switch 1.1.1.2 but reflecing the right IP address of course:

 

Create the access list:

access-list 105 permit 112 host 1.1.1.2 host 224.0.0.18

access-list 105 deny 112 any any

access-list 105 permit ip any any

 

Apply access list to the VLAN interface:

interface vlan 5

ip access-group 105 in

 

....this setup would definitly make sure that the switches can only recieve VRRP traffic from each other.  But what about preventing the "sniffing" of VRRP traffic?  Would I need to apply some other ACL "out"?

2 REPLIES 2
Peter_Debruyne
Honored Contributor

Re: Access Control Lists for Restricting VRRP Traffic

Just a question : why would you care about the sniffing of the VRRP traffic ?

A smart user can find your VRRP VRID anyway, simply based on the client arp cache, since the VRRP MAC is based on the VRID. And these switches do not support VRRP authentication, so no harm can be done there either ...

 

 

JohnLockie
Occasional Advisor

Re: Access Control Lists for Restricting VRRP Traffic

I would tend to agree with you on that point.

 

I think there's absolute value in preventing who is allowed to broadcast TO the switch on 224.0.0.18, but I am not sure the value in blocking the access layer from receiving these multicasts...

 

That said, I would be "hiding" (security through obscurity) the presense of VRRP on our network.  If one KNEW we were running VRRP (and I would think the only way is by discovering traffic on 224.0.0.18?), then yes they can use ARP records to find VRID, etc. (this topic I am not an expert on so really I am asking here not stating, if that makes sense).

 

As a side note, one response I have to this finding (to spare you the back story this issue was a finding in one of our audits, and I work in a regulated business) is that we secure the gateways NOT by securing VRRP, but by using dynamic ARP inspection, DHCP snooping, and IP spoofing prevention technicques.  Add on to this the inbound access list blocking anyone from sending multicast to our VRRP switches/routers we are pretty much doing our due diligence.