ACLs and HSRP, BGP, OSPF, VRRP, GLBP…

Posted on June 12th, 2008 in DHCP, EIGRP, ACLs, GLBP, HSRP, Cisco, BGP, Security by Aaron Conaway

Here’s a handy list of ACL entries to allow your devices to speak routing protocols, availability protocols, and some other stuff. We’ll assume you have ACL 101 applied to your Ethernet inbound; your Ethernet has an IP of 192.168.0.1.

  • BGP : Runs on TCP/179 between the neighbors

access-list 101 permit tcp any host 192.168.0.1 eq 179

  • EIGRP : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.10

access-list 101 permit eigrp any host 224.0.0.10

  • OSPF : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.5; also talks to 224.0.0.6 for DR/BDR routers

access-list 101 permit ospf any host 224.0.0.5
access-list 101 permit ospf any host 224.0.0.6

  • HSRP : Runs on UDP from the source interface IP to the multicast address of 224.0.0.2. I’ve seen in the past that it runs on UDP/1985, but I didn’t find any evidence of that in a quick Google for it. Can someone verify?

access-list 101 permit udp any host 224.0.0.2

  • RIP : Runs on UDP/520 from the source interface IP to the multicast address of 224.0.0.9

access-list 101 permit udp any host 224.0.0.9 eq 520

  • VRRP : Runs on its own protocol number from the source interface IP to the multicast address of 224.0.0.18

access-list 101 permit 112 any host 224.0.0.18

  • GLBP : Runs on UDP from the source interface IP to the multicast address of 224.0.0.102

access-list 101 permit udp any host 224.0.0.102

  • DHCPD (or bootps) : Runs on UDP/67 from 0.0.0.0 (since the client doesn’t have an address yet) to 255.255.255.255 (the broadcast).

access-list 101 permit udp any host 255.255.255.255 eq 67
If anyone else has one to add, do so in the comments.

Commenting Access-lists

Posted on March 12th, 2008 in PIX, ACLs, ASA, Firewall, Security, Cisco, InterNetworking by Aaron Conaway

There’s a very-overlooked feature of access-lists — the remark. Yes, this is very basic, but it’s worth mentioning, as it has saved me anguish time and time again.

I use remarks to document each line of an ACL (on IOS, PIX, FWSM, ASA, etc.) so that when I go back later, I actually know what I did. They’re simple to use, and, I promise you, you’ll thank yourself for using it when the CTO asks why access to TCP/80 is open from the Internet to the development server.

Easy to use.

access-list 101 remark This line allows access from the Internet to the development server. See ticket 1234
access-list 101 permit tcp any host 1.2.3.4 eq 80

Now, when you get asked the inevitable question, you can look at the line and know to check ticket 1234 for more information. The remark is just a string, so you can put what you want. I like to put source and destination hostnames, protocol/port, ticket number, and date/time the line was entered for reference like this.

access-list 2001 remark *** I’net — HTTP -> dev.example.com, Ticket 1234, 12Mar2008-0853 ***

It works with the ip access-list command as well.

ip access-list extended INBOUND
remark *** I’net — HTTP -> dev.example.com, Ticket 1234, 12Mar2008-0853 ***

It might be a good idea to use a remark to document what the ACL itself does. For example, on a firewall with 28974 interfaces, you might want to do something like this.

access-list DMZ1_OUT remark This ACL allows traffic out of the DMZ interface
access-list DMZ1_OUT remark *** ….
access-list DMZ1_OUT permit …