Outbound ACL per branch

[tedauction]

Hello, could someone please give me an example of a basic ACL which controls outbound traffic from any typical WAN site i.e. an ACL allowing only outbound traffic to the internet, DNS, DHCP and blocking everything else. My LAN being 192.168.1.0/24
My edge devices are layer 3 switches with SVI interfaces. How do you guys restrict what services your LAN clients can get out to ?

e.g. if I put the following on my SVI L3 interface on the edge switch/router would this work OK ?
I have DHCP helpers on the SVI L3 interface (192.168.1.1) pointing to DHCP server 192.168.2.1, so would I add the following to allow the DCHP helpers to work ?

permit udp 192.168.1.1 0.0.0.0 host 192.168.2.1 eq 67

ip access-list extended SVI_Outbound_ACL
permit tcp 192.168.1.0 0.0.0.255 host 10.6.2.1 eq 53 (to allow DNS)
permit udp 192.168.1.0 0.0.0.255 host 10.6.2.1 eq 53 (to allow DNS)
deny ip 192.168.1.0 0.255.255.255 10.0.0.0 0.255.255.255 (to block all other RFC1918 destinations)
deny ip 192.168.1.0 0.255.255.255 172.16.0.0 0.15.255.255 (to block all other RFC1918 destinations)
deny ip 192.168.1.0 0.255.255.255 192.168.0.0 0.0.255.255 (to block all other RFC1918 destinations)
permit tcp 192.168.1.0 0.0.0.255 any eq 80 ( to allow web outbound access)
permit tcp 192.168.1.0 0.0.0.255 any eq 443 ( to allow HTTPS outbound web access)
(default implicit deny all)

Then on my L3 edge switch SVI interface:
'ip access-group SVI_Outbound_ACL out'

[Julio E. Moisa]

Hi

There are 2 ways for extended ACL, numbered or named:

Sintaxis

Numbered:

access-list 100 permit <icmp/ip/tcp/udp, etc> <source host or subnet> <wildcard> eq <source port> <destination host or subnet> <wildcard> eq <destination port>

Named:

ip access-list extended TEST
permit <icmp/ip/tcp/udp, etc> <source host or subnet> <wildcard> eq <source port> <destination host or subnet> <wildcard> eq <destination port>

*If the source is a dynamic port you can omit the source port. 

interface GX/X or SVI
ip access-group <100 or TEST> out

Hope it is useful

:-)

[Julio E. Moisa]

Your config should be

ip access-list extended SVI_Outbound_ACL
permit tcp 192.168.1.0 0.0.0.255 host 10.6.2.1 eq 53 (to allow DNS)
permit udp 192.168.1.0 0.0.0.255 host 10.6.2.1 eq 53

*if you are using IP it will cover all the ports TCP/UDP so you don´t need to specify the destination port. DNS can work on both protocols TCP and UDP. 

If you are going to permit access to external DHCP you need something like:

permit udp any any eq 67
permit udp any any eq 68
permit udp any any range 137 139

* How the computers dont have IP initially, they are going to search a DHCP server using a broadcast IP (255.255.255.255), I remember the used ports are UDP bootpc and bootps. 

deny ip 192.168.1.0 0.255.255.255 10.0.0.0 0.255.255.255 (to block all other RFC1918 destinations)
deny ip 192.168.1.0 0.255.255.255 172.16.0.0 0.15.255.255 (to block all other RFC1918 destinations)
deny ip 192.168.1.0 0.255.255.255 192.168.0.0 0.0.255.255 (to block all other RFC1918 destinations)
permit tcp 192.168.1.0 0.0.0.255 any eq 80 ( to allow web outbound access)
permit tcp 192.168.1.0 0.0.0.255 any eq 443 ( to allow HTTPS outbound web access)

Are you sure you want  to block the private networks Classes? assuming it is a branch, you could lost connectivity to other sites. 

[tedauction]

thank you kindly.

I have a DHCP helper on the SVI L3 interface (192.168.1.1) pointing to DHCP server 192.168.2.1, so would I add the following to allow the DCHP helper and also DHCP renewals to work ?

permit udp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq 67

[Julio E. Moisa]

Hi,

Yes, you could, but you can keep the any any eq 67, When a new computer is requesting an IP address, it will generate a broadcast to find a DHCP server, once it is found the DHCP communication is started. 

[Joseph W. Doherty · Accepted solution]

For controlling what's allowed "out", you're on the right path, although often the question is more of what's allowed "in".

"In" can be done much like what you and/or Julio have posted for "out", but "in" ACLs might take advantage of two features not used for "out".

First, you might have an "in" ACE that allows any open TCP session using the established keyword.

Second, for TCP and/or other protocols that use symmetric flows, you might use a reflexive ACL.

BTW, having both "in" and "out" ACLs are not mutually exclusive.

For example, your "out" ACL allows web traffic out, but by also using an "in" ACL, you would only allow web traffic back in, i.e. a response from something started on the inside.