block rouge DHCP server on a vlan

[night-fury]

Hi,

I have very less exposure on access-lists. I am facing a problem where in we have identified a roughe DHCP server creating problems in network. I ran wireshark on a system and identified the roughe DHCP server IP to be 192.168.24.1 which is ACK DHCP requests from clinets only on VLAN1 in our multi VLAN based network setup. My VLAN subnet is 10.50.0.1 255.255.252.0.

I need to block this IP for that particular VLAN. I am seeking some help in the correct syntax to do so

access-list 101 deny ip 192.168.24.1 0.0.0.255 10.50.0.0 0.0.3.255

access-list 101 permit ip any any

.

.

apply on vlan 1

# interface vlan 1

ip access-group 101

is this correct? i have checked various write-ups but got a lil confused and want to confirm before i apply it !!

[Karsten Iwen · Accepted solution]

You are using the wrong tool for the right task. DHCP-Snooping is the tool that you should look at:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/12-2_52_se/configuration/guide/3750scg/swdhcp82.html#wp1058138

The link is for a 3750, but this feature should be available for all actual Access-Switches.

[night-fury]

Thank you Karsten. I will need to go through the document on DHCP snooping before I could configure it as I have not configured it before and since its a prodcution environment, I do not want to create any further problems as of now.

I was looking for an instant option to block the rogue server first and then find out and/or check other options. If i have to block it with the access-list as posted, is there smthin wrong with it, apart from being not a conventional method probably?

I will definitely look into DHCP snooping later though. Thanks for the link.

[night-fury]

i have configured DHCP snooping and seems to be working. i have some tests to run over the weekend, i will post back to confirm. thanks again.

[night-fury]

Hi,

as i mentioned, i configured DHCP snooping and its worked to block DHCP ACKs from rougue DHCP server. However, another problem arose.

I have a ghost server and due a VLAN based structure, I have mentioned the ghost server's IP add as 'ip helper-address'. All worked fine when DHCP snooping was not there and we were able to start ghost session in any of the VLANs via network PXE boot. However after enabling DHCP snooping, the clients are not able to boot from network.

I have configured 'ip dhcp snooping trust' where the ghost server, since it sends PXE boot requests, is connected but to no avail. Can you please help. DHCP server and ghost server are in same VLAN but on diff switches connected via port-channel.

Access switch - Cisco sg300

dhcp snooping enabled globally & for VLAN1

sw's port configured as trsuted where DHCP server is connected

Core sw: Cisco 3560

sw's port configured as trsuted where GHOST server is connected

attached is a diagram explaining the scenario.

-best

nf

[Paul Chapman]

Hi NF -

I added some markers to your diagram.  You should have trusted ports configured wherever the blue arrows point.  For Port-Channels, trust should be configured on the Port-Channel.

HTH

PSC

[night-fury]

Hey thanks Paul. I will make the changes and post back.

[night-fury]

funny thing, during the time i was configuring DHCP snooping, one of my colleagues enabled the windows firewall on Ghost server, so the connections were failing. took me a while to figure that out. Coz of the same timeline...i was suspecting that it has something to do with DHCP snooping.

As per Paul's suggestions I enabled trust on the ports he marked. All worked well.

Then just to test, I removed trust from port channels (only allowed on the ports marked in yellow). All worked fine again in VLAN 1 and across other VLANs too !

I guess defining trust on port channel is optional. Please correct me if I am wrong.

One question though:

Should DHCP snooping be enabled on core sw as best practice or is it ok to enable on the access sw where DHCP server is connected ?

Thank you Karsten for pointing me in the right direction and Paul for your valuable inputs.

[Paul Chapman]

Most commands applied to the Port-Channel interface will get inherited by the underlying physical interfaces.  Generally it is a best practice to make your configuration changes there.

In the overall DHCP snooping configuration, it is best practice to apply it to any switch that is patched to a location that you don't control (wall plates, cubicles, etc...).  In organizations that deploy snooping, it is configured on all access switches.  The point is to prevent rogue DHCP servers from getting on the network and this feature is oriented toward the ports where rogues may be.

PSC

[tjreeddoc]

All,

Good discussion!

I'm testing DHCP Snooping in a lab. It definitely blocks a rogue DHCP server! However, I'm not getting Syslog messages stating DHCP Snooping dropped the packet.  

When I turn on the debugs ip dhcp snooping event and ip dhcp snooping packet, I see message a packet was dropped. But, I don't want to constantly run a debug.  

What do I need to do to get a Syslog message when dhcp snooping drops a packet from a rogue DHCP server?

T.J.

[Paul Chapman]

Hi TJ -

My guess would be that you probably need to monitor it with SNMP.  I don't know the OID off the top of my head, but there must be a counter you can access.

PSC

[night-fury]

 ...