DHCP quits when ACL applied

Unanswered Question
Sep 30th, 2008
User Badges:

I have a 1760 that routes traffic between 3 VLANS and the Internet. VLAN1 can also get to VLAN5 and VLAN10, but not the other way around. DHCP works fine until the ACL is placed on the subinterfaces of F0/0. Any help will be appreciated.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Richard Burts Tue, 09/30/2008 - 17:57
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Lewis


You describe the problem as being an issue with DHCP when you apply the access lists. But I am seeing several problems but not particularly problems with DHCP. If I have not understood something correctly then please clarify so that I can understand better.


Your config indicates that VLAN 1 is interface FastEthernet0/0.1. But it also indicates that VLAN 5 is interface FastEthernet0/0.1. And it indicates that VLAN 10 is interface FastEthernet0/0.1. That would certainly create problems for a start.


Then you indicate these results from one of the PCs:

ON VLAN10

IP: 192.168.10.50

Gateway: 192.168.15.254

But the IP address is in one subnet and the gateway is in a different subnet. That does not match what you show for the DHCP config. So either what you have posted is not correct or this PC has hard coded information and is not learning address and gateway from DHCP. Can you clarify which it is?


And in access list 101 you deny any traffic with source address in 192.168.15.0 or 192.168.10.0 (which covers VLAN 5 and VLAN 10) to 192.168.20.0. So a PC in VLAN 1 could send something to any device in VLAN 5 or VLAN 10, but the response coming back would be denied. So there is effectively no communication from VLAN 1 to VLAN 5 or 10 once you apply the access list.


If you can correct these issues and there is still a problem then please post updated configs and a fresh description of what is not working.


HTH


Rick

lhoyle Wed, 10/01/2008 - 05:26
User Badges:

Rick,


I was cutting and pasting like a madman when I created that document. I just looked at the config and the sub ints are correct (f0/0.1, f0/0.5, f0/0.10). Sorry for the confusion on that. As far as the DHCP is concerned, my customer ran IP configs and that indeed is what he got. That is why I am so confused.


I had the customer run the "ipconfig" becasue I wondered if the DHCP server would be different than the IP address of the subint. That was why I thought the DHCP was failing. I will do more research today.


lhoyle Wed, 10/01/2008 - 05:35
User Badges:

Revised ACL for VLAN 1


access-list 101 permit ip any 192.168.20.0 0.0.0.255 established

access-list 101 deny ip 192.168.15.0 0.0.0.255 192.168.20.0 0.0.0.255

access-list 101 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255

access-list 101 permit ip 192.168.20.0 0.0.0.255 any

access-list 101 permit ip 192.168.21.0 0.0.0.255 any



Richard Burts Wed, 10/01/2008 - 12:09
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Lewis


It looks like there should be an attached file but there is no file to download. I am not sure what the issue is but perhaps you could put the revised config up again?


HTH


Rick

lhoyle Wed, 10/01/2008 - 12:12
User Badges:

Here it is...



service password-encryption

!

hostname Rtr1760

!

no aaa new-model

!

resource policy

!

!

!

ip dhcp excluded-address 192.168.20.1 192.168.20.49

ip dhcp excluded-address 192.168.20.151 192.168.20.254

ip dhcp excluded-address 192.168.15.1 192.168.15.49

ip dhcp excluded-address 192.168.15.151 192.168.15.254

ip dhcp excluded-address 192.168.10.1 192.168.20.49

ip dhcp excluded-address 192.168.10.151 192.168.10.254

address 192.168.20.1 client-id 0013d3f4ce7c

address 192.168.15.1 client-id 001517175c14

!

ip dhcp pool vlan1

network 192.168.20.0 255.255.255.0

default-router 192.168.20.254

dns-server 203.x.x.191 203.215.29.191

!

ip dhcp pool vlan5

network 192.168.15.0 255.255.255.0

default-router 192.168.15.254

dns-server 203.x.x.191 203.215.29.191

!

ip dhcp pool vlan10

network 192.168.10.0 255.255.255.0

default-router 192.168.10.254

dns-server 203.x.x.191 203.215.29.191

!

!

!

interface FastEthernet0/0

no ip address

duplex auto

speed auto

!

!

interface FastEthernet0/0.1

descr vlan 1

ip access-group 101 out

ip address 192.168.20.254 255.255.255.0

ip nat inside

!

interface FastEthernet0/0.5

descr vlan 5

ip access-group 105 out

ip address 192.168.15.254 255.255.255.0

ip nat inside

!

interface FastEthernet0/0.10

descr vlan 10

ip access-group 110 out

ip address 192.168.10.254 255.255.255.0

ip nat inside

!

access-list 101 permit ip any 192.168.20.0 0.0.0.255 established

access-list 101 deny ip 192.168.15.0 0.0.0.255 192.168.20.0 0.0.0.255

access-list 101 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255

access-list 101 permit ip 192.168.20.0 0.0.0.255 any

access-list 101 permit ip 192.168.21.0 0.0.0.255 any

!

access-list 105 deny ip 192.168.10.0 0.0.0.255 192.168.15.0 0.0.0.255

access-list 105 deny ip 192.168.15.0 0.0.0.255 192.168.21.0 0.0.0.255

access-list 105 deny ip 192.168.15.0 0.0.0.255 192.168.20.0 0.0.0.255

access-list 105 permit ip any 192.168.15.0 0.0.0.255

!

access-list 110 deny ip 192.168.15.0 0.0.0.255 192.168.10.0 0.0.0.255

access-list 110 deny ip 192.168.10.0 0.0.0.255 192.168.21.0 0.0.0.255

access-list 110 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255

access-list 110 permit ip any 192.168.10.0 0.0.0.255

!

!



When my client does a "ipconfig /all" from each subnet, he gets...


ON VLAN10

IP: 192.168.10.50

Gateway: 192.168.15.254

DHCP: 192.168.10.254

DNS: 203.x.x.191 203.215.29.19


ON VLAN5

IP: 192.168.15.50

Gateway: 192.168.15.254

DHCP: 192.168.15.254

DNS: 203.x.x.191 203.215.29.19


ON VLAN1

IP: 192.168.20.59

Gateway: 192.168.20.254

DHCP: 192.168.20.254

DNS: 203.x.x.191 203.215.29.19




Richard Burts Wed, 10/01/2008 - 13:34
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Lewis


I do not believe that the PC in vlan 10 where they did ipconfig got its address from DHCP. The gateway assigned is the gateway for vlan 5 and not the one for vlan 10. Doing ipconfig is not enough. They need to go to the PC, go to network, to the interface, and check the properties. I would guess that this address was hard coded and not learned from DHCP.


Beyond that I see some issues in the way that the access lists are configured. Access list 101 is applied outbound on vlan 1. In that case 192.168.20.0 should be the destination address in the access list. I like the addition of permit tcp established which should work. The deny statements for traffic from vlan 5 and 10 are slightly problematic for any response to traffic originating from vlan 1 that uses UDP or ICMP since it will deny those responses as well as denying traffic originated from vlan 5 and 10. And the last 2 permit statements are backwards since they position 192.168.20.0 as the source address:

access-list 101 permit ip 192.168.20.0 0.0.0.255 any

access-list 101 permit ip 192.168.21.0 0.0.0.255 any


In access list 105 the first line does effectively deny traffic from vlan to vlan 5 as desired. But the next 2 statements have reversed the source and destination aspects of the traffic and therefore will not work as intended:

access-list 105 deny ip 192.168.15.0 0.0.0.255 192.168.21.0 0.0.0.255

access-list 105 deny ip 192.168.15.0 0.0.0.255 192.168.20.0 0.0.0.255


There are similar issues in access list 110.


HTH


Rick

lhoyle Wed, 10/01/2008 - 13:44
User Badges:

Rick,


Thanks for your help. I'm a noob on this type of thing. See if you think these will work better. If so, I'll send them off to my client for testing.


!

interface FastEthernet0/0.1

descr vlan 1

ip access-group 101 out

ip address 192.168.20.254 255.255.255.0

ip nat inside

!

interface FastEthernet0/0.5

descr vlan 5

ip access-group 105 out

ip address 192.168.15.254 255.255.255.0

ip nat inside

!

interface FastEthernet0/0.10

descr vlan 10

ip access-group 110 out

ip address 192.168.10.254 255.255.255.0

ip nat inside

!

access-list 101 permit ip any 192.168.20.0 0.0.0.255 established

access-list 101 permit icmp any 192.168.20.0 0.0.0.255 established

access-list 101 permit udp any 192.168.20.0 0.0.0.255 established

access-list 101 deny ip 192.168.15.0 0.0.0.255 192.168.20.0 0.0.0.255

access-list 101 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255

!

access-list 105 deny ip 192.168.10.0 0.0.0.255 192.168.15.0 0.0.0.255

access-list 105 permit ip any 192.168.15.0 0.0.0.255

!

access-list 110 deny ip 192.168.15.0 0.0.0.255 192.168.10.0 0.0.0.255

access-list 110 permit ip any 192.168.10.0 0.0.0.255

!

!



Richard Burts Wed, 10/01/2008 - 19:04
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Lewis


Unfortunately it is not any better. established works for TCP but not for UDP or for ICMP. So these lines are invalid and would produce syntax errors if entered into config mode:

access-list 101 permit icmp any 192.168.20.0 0.0.0.255 established

access-list 101 permit udp any 192.168.20.0 0.0.0.255 established


HTH


Rick

lhoyle Thu, 10/02/2008 - 05:53
User Badges:

Weould this be better?


access-list 101 permit icmp any any echo-reply

access-list 101 permit icmp any any unreachable

access-list 101 permit icmp any any time-exceeded

access-list 101 deny icmp any any

access-list 101 permit udp any range 1 1023 192.168.20.0 0.0.0.255 gt 1023


Thanks,

Lee


Richard Burts Thu, 10/02/2008 - 06:46
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Lee


If these are the only 3 ICMP messages that you want then yes this would be better.


HTH


Rick

andrew.butterworth Thu, 10/02/2008 - 07:21
User Badges:
  • Gold, 750 points or more

DHCP still won't work though as the IP source for a broadcast DHCP discovery is 0.0.0.0 and the destination is 255.255.255.255 (UDP source 68, destination 67). You would need to include this in the ACL to allow DHCP clients to get an IP address.


HTH


Andy

lhoyle Thu, 10/02/2008 - 07:36
User Badges:

Like this?


access-list 101 permit udp any eq 68 any eq 67

access-list 105 permit udp any eq 68 any eq 67

...and so on.


Thanks,

Lee


andrew.butterworth Thu, 10/02/2008 - 07:40
User Badges:
  • Gold, 750 points or more

Yes, that will do it. DHCP also uses unicast half way through the lease time to check the address is still OK. However the port numbers are the same so the lines you posted will cover them.


Andy

Richard Burts Thu, 10/02/2008 - 11:21
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Andy


Your point would be more valid if the access list were applied as inbound, in which case the DHCP must be permitted. But since the access list is applied out, and since an outbound access list does not check traffic generated by the router itself then I believe that DHCP would work without the modification to the access list.


HTH


Rick

andrew.butterworth Thu, 10/02/2008 - 11:40
User Badges:
  • Gold, 750 points or more

I only skimmed through the thread and didn't realise they were applied outbound.... My fault for not reading deep enough.

I thought you would still need the lines in there (reversed) even if the router is the DHCP server though? I have never seen a reference to the processing order showing that router generated traffic is exempt from outbound ACL processing?


Andy

Richard Burts Thu, 10/02/2008 - 12:00
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Andy


It is hard to find it written down clearly, but it is the case (and has always been the case) that an outbound access list will not filter traffic that is generated by the router itself. It is easy to check in the lab.


So as long as the router is the DHCP server there is no need to permit DHCP traffic in an outbound access list.


HTH


Rick

andrew.butterworth Thu, 10/02/2008 - 12:10
User Badges:
  • Gold, 750 points or more

You live and learn!!!!


I'll have a play around with this in the lab tomorrow as this is something that has somehow bypassed me (in all my years of doing this stuff...)


Andy

lhoyle Fri, 10/03/2008 - 05:02
User Badges:

I really appreciate Andy and Rick's comments. They have been very beneficial for me! Thank you again!

andrew.butterworth Sat, 10/04/2008 - 05:45
User Badges:
  • Gold, 750 points or more

Just to finish this one off I tried this in the lab yesterday and it does indeed do what Rick said - i.e. router generated traffic bypasses egress ACL processing.


I have some autonomous WiFi AP's all connected to the same Layer-3 PoE switch, currently there is an inbound ACL attached the SVI that the 'Guest' SSID is bound to. This ACL allows some restictive access to Wireless 'Guests':


ip access-list extended Guest-Wireless

permit udp any any range bootps bootpc

permit udp 10.99.99.0 0.0.0.31 host 192.168.100.10 eq domain

deny ip any 192.168.0.0 0.0.255.255

permit tcp 10.99.99.0 0.0.0.31 gt 1023 any eq www

permit tcp 10.99.99.0 0.0.0.31 gt 1023 any eq 443

!


They can get an IP address via DHCP, use one of the internal DNS Servers for name resolution but can't reach any other internal host and then can use HTTP & HTTPS to hosts on the internet. I then created another ACL by reversing this one and also removing the DHCP entries (UDP 67-68). When this was then applied and a WiFi client disconnected and then re-connected it continued to work proving the DHCP responses were bypassing the egress ACL. I was a bit surprised at this at first as the DHCP server is somewhere else and not on the switch, however an IP Helper is configured on the SVI so the client DHCP broadcast packets are encapsulated by the SVI and unicast to the DHCP server that in turn replies via unicast to the switch. The switch then de-encapsulates the packet and unicasts it back to the DHCP client, so it is traffic generated by the router.


You learn something new everyday...


Andy

Richard Burts Sun, 10/05/2008 - 11:54
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Andy


Thanks for posting back with the results of your testing (and thanks for confirming what I had said). I agree that it is not the behavior that you would expect from a purely logical perspective (that an access list applied outbound would not filter traffic generated by the router). But it has consistently been the behavior of IOS.


HTH


Rick

Actions

This Discussion