Allow DHCP flow in Cisco extended access list

[RookieNet55]

I am trying to setup a Guest VLAN and my dhcp server is on a different vlan.

This guest vlan is internet only access, so I am denying all private address and ssh to SVI of vlan 901. So far everything works fine except for dhcp assignment

This is the extended ACL I have

Extended IP access list GUEST_LAN_901_IN
1 deny tcp any host 10.211.252.1 eq 22
50 permit udp any eq bootpc any eq bootps
100 permit ip any any
Extended IP access list GUEST_LAN_901_OUT
5 permit udp any eq bootpc any eq bootps
10 permit ip 10.211.252.0 0.0.0.255 10.211.252.0 0.0.0.255
20 deny ip 172.16.0.0 0.15.255.255 any
30 deny ip 172.32.0.0 0.7.255.255 any
40 deny ip 192.168.0.0 0.0.255.255 any
50 deny ip 10.0.0.0 0.255.255.255 any
60 permit ip any any

This is the SVI interface with the acl applied

interface Vlan901
description Guest-VLAN
ip address 10.211.252.1 255.255.255.192
ip helper-address 172.16.x.x
ip helper-address 172.18.x.x
ip access-group GUEST_LAN_901_IN in
ip access-group GUEST_LAN_901_OUT out
end

Would appreciate any guidance or help. I have a feeling it is about ACL IN and OUT direction, but felt it is better to clarify in community.

[Jens Albrecht]

For the DHCP return traffic you need to swap the ports because this traffic is coming from the server destined to the clients:

Extended IP access list GUEST_LAN_901_OUT
5 permit udp any eq bootps any eq bootpc

There are a few things you can do to troubleshoot such issues:

• Use the "show access-list" command to check which entries of your access-list have matches
• Check your DHCP server whether it receives the requests and sends an offer back
• If you are familiar with debug commands you can use e.g. "debug ip dhcp server events" and "debug ip dhcp server packet" to monitor the DCHP process

HTH!

[RookieNet55]

Thank you for the response. That makes sense. I did make that change, but no luck. I will ahve to make some research on how to use the debug commands to check the dhcp packets. I was also reading in other forums where you need to specify the actual DHCP server address in access list for it to work.

sh ip access-lists interface vlan 901
Extended IP access list GUEST_LAN_901_IN
    1 deny tcp any host 10.211.252.1 eq 22
    50 permit udp any eq bootpc any eq bootps
    100 permit ip any any
Extended IP access list GUEST_LAN_901_OUT
    5 permit udp any eq bootps any eq bootpc
    10 permit ip 10.211.252.0 0.0.0.255 10.211.252.0 0.0.0.255
    20 deny ip 172.16.0.0 0.15.255.255 any
    30 deny ip 172.32.0.0 0.7.255.255 any
    40 deny ip 192.168.0.0 0.0.255.255 any
    50 deny ip 10.0.0.0 0.255.255.255 any
    60 permit ip any any

[Jens Albrecht]

@RookieNet55 wrote:

I was also reading in other forums where you need to specify the actual DHCP server address in access list for it to work.

No need to do that, a general ANY is enough to function. The ACL looks good now and I just confirmed this by setting up a quick lab based on your information. My dhcp client does get an IP address with both ACLs in place without any problems.

Did you test that everything is working fine BEFORE implementing your ACLs?
So did you confirm IP connectivity to the dhcp server? Does dhcp assignment work if you remove the ACLs?
As mentioned above everything works just fine in my lab so there should be some other issue with your setup.

Regarding the debug comands I put an example just taken from the switch of my lab for your reference so that you can see what to look for. I only removed the timestamps of each entry to improve readability:

Command: debug ip dhcp server packet

Output:

DHCPD: Reload workspace interface Vlan901 tableid 0.
DHCPD: tableid for 10.211.252.1 on Vlan901 is 0
DHCPD: client's VPN is .
DHCPD: using received relay info.
DHCPD: Looking up binding using address 10.211.252.1
DHCPD: setting giaddr to 10.211.252.1.
DHCPD: BOOTREQUEST from 0063.6973.636f.2d35.3235.342e.3030.6666.2e36.3534.322d.4769.302f.30 forwarded to 172.16.1.1.
DHCPD: Reload workspace interface Vlan25 tableid 0.
DHCPD: tableid for 172.16.1.100 on Vlan25 is 0
DHCPD: client's VPN is .
DHCPD: forwarding BOOTREPLY to client 5254.00ff.6542.
DHCPD: no option 125
DHCPD: broadcasting BOOTREPLY to client 5254.00ff.6542.
DHCPD: Reload workspace interface Vlan901 tableid 0.
DHCPD: tableid for 10.211.252.1 on Vlan901 is 0
DHCPD: client's VPN is .
DHCPD: Finding a relay for client 0063.6973.636f.2d35.3235.342e.3030.6666.2e36.3534.322d.4769.302f.30 on interface Vlan901.
DHCPD: Looking up binding using address 10.211.252.1
DHCPD: setting giaddr to 10.211.252.1.
DHCPD: BOOTREQUEST from 0063.6973.636f.2d35.3235.342e.3030.6666.2e36.3534.322d.4769.302f.30 forwarded to 172.16.1.1.
DHCPD: Reload workspace interface Vlan25 tableid 0.
DHCPD: tableid for 172.16.1.100 on Vlan25 is 0
DHCPD: client's VPN is .
DHCPD: forwarding BOOTREPLY to client 5254.00ff.6542.
DHCPD: no option 125
DHCPD: broadcasting BOOTREPLY to client 5254.00ff.6542.

As you can see from this output my dhcp server is connected via VLAN 25 with the IP address 172.16.1.1 to meet the network for the ip helper-address you mentioned.

In case you still face issues we need more details about your setup like network diagram and full config.

HTH!

[paul driver]

Hello

---

@RookieNet55 wrote:

Thank you for the response. That makes sense. I did make that change, but no luck. I will ahve to make some research on how to use the debug commands to check the dhcp packets. I was also reading in other forums where you need to specify the actual DHCP server address in access list for it to work.

sh ip access-lists interface vlan 901
Extended IP access list GUEST_LAN_901_IN
    1 deny tcp any host 10.211.252.1 eq 22
    50 permit udp any eq bootpc any eq bootps
    100 permit ip any any
Extended IP access list GUEST_LAN_901_OUT
    5 permit udp any eq bootps any eq bootpc
    10 permit ip 10.211.252.0 0.0.0.255 10.211.252.0 0.0.0.255
    20 deny ip 172.16.0.0 0.15.255.255 any
    30 deny ip 172.32.0.0 0.7.255.255 any
    40 deny ip 192.168.0.0 0.0.255.255 any
    50 deny ip 10.0.0.0 0.255.255.255 any
    60 permit ip any any

---

I agree with @Jens Albrecht  that acl shouldn't not negate any dhcp allocation now that you have change ACE 5 to to originate bootps in that outbound ACL

As also suggested have you tried removing it from the SVI and test

Note:  SVI avl logic
IN = Originating  from withing SVI
OUT= Originating from outside svi 

[MHM Cisco World]

SVI ACL is reverse to L3 ACL

I.e. try below 

ip access-group GUEST_LAN_901_IN OUT
ip access-group GUEST_LAN_901_OUT IN

MHM