Showing results for 
Search instead for 
Did you mean: 

DHCP snooping problem / untrusted port permit DHCP packet

Level 1
Level 1

Dear Community!

There is a strange thing I just can not understand related to the following scenario:

I have two VLANs (200, 201)

One rogue DHCP-server per VLAN200 and VLAN201

DHCP-clients are in VLAN200.

We have a 1941 router with two subinterfaces configured, the one dedicated to VLAN200 has an ip-helper address pointing to rogue DHCP-server of VLAN201.

We have a switch, configured fully with VLANs, trunks plus dhcp snooping, dhcp snooping vlan 200,201.


So the problem is that VLAN200 rogue DHCP server is unable to share DHCP for the clients in the same VLAN

But clients get DHCP from VLAN201 rogue DHCP server.

I checked show ip dhcp and all affected ports are untrusted! And yet, clients still get IP from the rogue DHCP-server from different VLAN.

Any advice or help would be appreciated.

Thank You


10 Replies 10

Can you share config 


Dear MHM!


Here it is:


ip dhcp snooping vlan 200-201
ip dhcp snooping

interface FastEthernet0/1
switchport access vlan 200
switchport mode access
interface FastEthernet0/2
switchport access vlan 200
switchport mode access
interface FastEthernet0/3
switchport access vlan 201
ip dhcp snooping trust
switchport mode access

NOTE: TRUSTED DHCP-server is shut down for testing purposes

interface FastEthernet0/4
switchport access vlan 200
switchport mode access
interface FastEthernet0/5
switchport access vlan 201
interface GigabitEthernet0/1
ip dhcp snooping trust
switchport mode trunk

Switch#show ip dhcp sn
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
Insertion of option 82 is enabled
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Interface Trusted Rate limit (pps)
----------------------- ------- ----------------
FastEthernet0/4 no unlimited
FastEthernet0/1 no unlimited
FastEthernet0/2 no unlimited
FastEthernet0/3 yes unlimited
FastEthernet0/6 no unlimited
FastEthernet0/5 no unlimited
GigabitEthernet0/1 yes unlimited


check the topology 
am I correct?
if Yes check the note I add to topology 

Screenshot (137).png

Dear MHM!

Thank You for the quick response. The only difference between your scenario and mine is that I use router instead of L3 switch for intervlan routing purposes. Here I attach my topology:

2024-02-23 07_32_56-Cisco Packet Tracer - I__TANÍTÁS_DHCP-snooping-vlan.pkt.png

The problem in a nutshell: snooping protects the VLAN200 from internal attacks, but not from external attacks.

1-the DHCP and clinet in same VLAN , here the ip dhcp snooping stop rogue by config trust port toward trust DHCP and any other port are not trust here the rogue can not answer DHCP request 
2- the DHCP and client in different VLAN, here the ip helper is protect the client from rogue, how the rogue receive the DHCP request if the relay not forward it? 

so ip dhcp snooping indeed protect internal attacks 
and relay protect external attacks 


Dear MHM!

Thank You for the response. Indeed, it seems quite unusual, that the attacker has the same IP as the trusted DHCP, but we are testing a scenario where the trusted device becomes unreacheable (following a DDOS attack or something similar) and the attacker sets the same IP as the trusted one. So, the question is: why does untrusted VLAN201 ports let DHCP-offers from the rogue-DHCP device to VLAN200 devices? (Extra: it is not shown in my topology but later we added DHCP-client devices to VLAN201, and as expected, they did not get DHCP-offers from VLAN201 rogue-DHCP - they were safed by snooping.)

now assume that the Attacker use same IP of DHCP and DHCP is under DDoS still if the port connect to hacker DHCP is not trust the DHCP not work. 

Screenshot (138).png


Its seems you may not quite understand how DHCP snooping works (or I didn't understand your problem fully). DHCP snooping is meant to prevent a DHCP server from sending its messages (Offer/ACK) on untrusted ports. The way you describe your configuration it seems both VLAN 200 and 201 devices are using their respective sub interfaces as their DG to get an IP address. As you mentioned you have the "Rogue" DHCP server configured as a helper address under the respective interfaces. If this is correct then that wont work. Think about how DHCP snooping works. Only trusted ports are allowed to send DHCP server message types. So if your Rogue DHCP server is coming form the same interface (trunk to router using subinterfaces) then its definitely allowed. DHCP snooping prevents DHCP Server messages on UNTRUSED ports only. So if your Rogue DHCP server is sending its messages to the same port the legitimate DHCP server is sending them to and its a trusted port then it will be allowed. The DHCP snooping has no way of determining what's rogue and what isn't if both devices are sending on a trusted port. Untrusted ports are allowed to forward Server and client messages but only allowed to receive client message type (Discover/Request).


Hope that helps and if I am mistaken in your config can you please clarify.



Dear David!


Thank You for responding. Indeed, my description was not 100% clear. In short, the problem is that the attacking DHCP server is able to provide DHCP services to another VLAN and is unable to do so to its own VLAN via the untrusted port. Above I have attached the switch configuration, which shows that only the router-facing trunk port and the trusted DHCP server-facing port are trusted, the rest are untrusted. My question is, is there any way to prevent the attacking DHCP server from providing DHCP services not only to its own VLAN, but also to another VLAN? (Ip-helper address points to the good DHCP server, but assume that the attacker IP is the same, and the trusted DHCP server becomes unreachable)


If you have the interface connected to the server as not trusted then the DHCP Server messages should not eb going through. Try to run a debug ip dhcp snooping packet on your switch to see how its being processed. Here is what my output looked like:


Once I enabled DHCP snooping trust on the interface the output looked like this:


Processed as normal.

Also as @MHM Cisco World mentioned you should disable option 82 with the command:

no ip dhcp snooping information option


Review Cisco Networking for a $25 gift card