• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 798
  • Last Modified:

Why are my access-lists on VLANS mucking up ip helper?

I'm in a hotel which doesn't allow vpn out, so I don't have the config to post right now.  Hopefully my explanation will give enough information to get some good feedback.

4 VLANS on Cisco 3560 switch.
VLAN 100, 111, 112, 113

DHCP Server is

I configured each VLAN with the ip helper to  inter-VLAN routing is working fine.

Hosts on VLAN 111 can not get an IP address from the DHCP server.
If I remove the access-lists from both VLANs then everything works, so I'm thinking thre access-list is blocking some necessary port.  We tried allowing the two dhcp related UDP ports through but it didn't work.  Wondering what other ports to try.  

For a variety of reasons I need to block access between the VLANs all but the absolutely necessary ports.

I do not know if the virtual intefaces are configured for ip directed broadcasts or not.  I'll check that tomorrow.

Any suggestions on what else to look for?  

  • 2
  • 2
  • 2
  • +2
1 Solution
What addresses were permitted when you allowed the two DHCP-related (bootp-related?) UDP ports?  You can't allow the traffic assuming it's coming from a local IP address - it'll come from (I think) and go to (I think).
Don JohnstonInstructorCommented:
Short of seeing the ACL, I can't think of anything else.
averybAuthor Commented:
I am trying to allow hsots on VLAN 112 to get an IP address from a DHCP on VLAN 100.
Access-list 112 grouped on VLAN 112 gateway
   10 permit icmp any any
    20 permit udp any host eq bootps
    30 permit udp any host eq bootpc
    40 permit ip any
    50 permit ip any
    60 permit ip
    70 permit tcp any any eq ftp
    80 permit tcp any eq 3389
    90 permit ip host host
    100 permit ip host host
    110 permit tcp host any eq smtp
    120 deny tcp host eq www
    130 deny tcp host eq www
    140 deny tcp eq www
    150 deny tcp eq www
    160 permit tcp host any eq www
    170 permit tcp any eq www
    180 permit ip

Access list 100 applied to VLAN 100 gateway
    10 permit icmp any any (4 matches)
    20 permit udp host any eq bootps (52 matches)
    30 permit udp host any eq bootpc (59 matches)
    40 permit tcp any any eq ftp
    50 permit tcp any any eq 3389
    60 permit tcp any any eq 2000
    70 permit ip host any
    80 permit ip host any
    90 permit ip any
    100 permit ip any
    110 permit ip any
    120 permit ip host host
    130 permit ip host host
    140 permit ip host host
    150 permit ip host host
    160 permit ip host host
    170 permit ip host host
    180 deny ip any
    190 deny ip any (1 match)
    200 deny ip any

The matches on the ace's are left over from some testing.  If no access-list is applied to either VLAN interface then everythin works.

interface Vlan100
 ip address
 ip access-group 100 in

interface Vlan112
 ip address
 ip access-group 112 in
 ip helper-address

Does ip directed broadcasts need to be configured for the interfaces?

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Don JohnstonInstructorCommented:
Change lines 20 & 30 on ACL 100

    20 permit udp host eq bootps any
    30 permit udp host eq bootpc any

And/or simply write the entries twice, once in each direction.
I think the problem is that the ACLs are applied before the ip helper-address is applied, so as mentioned earlier, the destination address is a broadcast So aside from donjohnston's changes above, also do this on access-list 112

    20 permit udp any host eq bootps    
    25 permit udp any host eq bootps
    30 permit udp any host eq bootpc
    35 permit udp any host eq bootpc

Once the client knows who the server is, he will talk to it. But until then he will send a broadcast and you need to allow for that.
DHCP requests are sent from the clients as broadcasts.  They will not (cannot) be routed.

The helper captures the broadcast requests, and re-sends them as (routable) UDP unicasts.  To service such a relayed request, the DHCP server needs to know what subnet the request was relayed from (i.e., relaying device's IP address on the interface that saw the broadcast), and have a scope that lies within that subnet.

Doesn't matter. He's using ip helper. The current access-list will cause the router to drop the broadcasts and not even process them, so they never get converted to unicast.

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 2
  • 2
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now