hello all.

today i had a problem wtih rogue dhcp traffic from users plugging in their routers returning dhcp onto my hotspot causing a problem.

i found this in the wiki however i dont use a bridge as in the example.

can someone help please?

http://wiki.mikrotik.com/wiki/Bridge_Fi ... CP_Traffic

As posted and said many times in the forum, the only way to mitigate this problem and resolve it is to have your layer2 network set up in such as way as to prevent this. This means managed switches with port isolation, and access points with client isolation at the very least. There are other options available on more expensive switches as well for additional security and user control.

This has never been something that a router can solve since the router is just a layer3 hop in the network. It cannot control what people at the edge of the network broadcast or inject into the network. The only way for a router to control and firewall traffic is to have that traffic flow over it.

thank you for the quick reply.

i have done this so far...

i have enabled authoritative=yes on my dhcp server in routeros
then i set a filter rule whats funny about this rule is i am seeing traffic grow rapidly.

now about managed switches.
i have the clients connected to a dell poweredge 2748 managed switched. not as powerful as a cisco but still gigabit ports that are managed.
i am not exactly sure what i could set on the switch to stop return dhcp traffic.
and i realize this is not a dell forum. lol. but a pointer would be great.

The option in switches is usually something like port isolation or protected ports, or something along those lines. The idea is that any frames that enter into a "protected" port will not be allowed to leave another "protected" port. You can also achieve this via VLANs if they are supported. Not all managed switches support protected ports.

Your firewall really won't do anything to a rouge DHCP other than possibly letting you know it exists on the network, though that isn't always very reliable either.

How are those clients connecting into your network? Directly into the switch?

Feklar: sadly the most powerful managed switch my company has is a poweredge 2748 and it doesnt have anything near that feature.

jvr: yes. via switch

so (question-1)what i dont understand still is this: i have a dhcp server running on my network for hotspot. the clients all have dhcp ips issued to them and they are working gracefully. how is it someone plugs in a router that broadcasts dhcp can stop even those with an IP?

my isp actually detected the problem using the packet sniffer. he was the one that gave me the mac addresses of the offending routers.

this whole dhcp rogue thing is very new to me and i am totally freaked out by it now.

(question-2) vlans. at least my switch supports vlans. do i setup vlans on the switch for isolation or on the mt router? would i need 48 vlans for 48 users?

DHCP works by broadcast, so if someone plugs in a DHCP server on your network it'll fight with your DHCP server and may the best router win. Obviously that leads to problems. In the case of our WAN we use radios that can block DHCP server responses at the customer's ethernet port, and in cases where people can plug in via ethernet it is usually a bridged router where I can firewall off DHCP server responses.

If your switch can't block that you'll have to get creative.

- From what I can see the 2748 supports VLANS. You could make say 47 VLANs (or however many ports you need on the hotspot side) on the ethernet port on the router that connects to the switch. Number and name the VLANs after the switch port numbers (VLAN2, VLAN3, VLAN4 ... VLAN48) just to keep it straight in your head. Bridge them all together, assign your hotspot IP to the bridge, and then assign the hotspot/DHCP server/etc to the bridge. Now make the port on the switch that the router connects to a trunk port (make it a member of all 47 VLANs). Then, assign all the rest of the ports on the switch a separate access VLAN that matches that name/number. At this point each port on the switch will have to pass broadcast traffic through the bridge. On the router change the bridge settings to "Use IP Firewall". Now you should be able to make a firewall rule that blocks all DHCP server traffic - you'd need to block any forwarded traffic to the bridge with a destination port of UDP 68. Keep in mind that this would -not- be very efficient but it may work for you, it depends on how much traffic the hotspot users are doing. For the tagging/untagging of the switch ports you are on your own since I don't know Dell switches at all. I did something like this at one location a year or so back but with only a few ports - I think it was a shared office building with a crappy Netgear 16 port managed switch and a Routerboard 750. This is all of the top of my head and I'm sure I'm missing something but it should work.

- Or, depending on how may hotspot users who plug-in that you have, you could get a 493 or a 493G (if you have to have gigabit ports) and bridge/block the same way as above minus the VLANs. You just make them plug into the 493 instead of the switch. If you have 40 ethernet hotspot users then obviously a 493 wouldn't work (only 9 ports, so a max of 8 hotspot clients each).

wow thanks for that great reply, jvr.

this would be my very first time working on vlans... doesnt sound all that difficult..

i think option 3 would be to work on creating a firewall filter on the sxts.

currently i have the system setup like this:

main office internet --sxt bridge <--> sxt station bridge --> poweredge switch 2748

so with that, would it be best to setup a bridge port on both sxts, and then add the firewall filter to block port 68?

There is actually an easier way of blocking communication between bridged ports on a routerboard than with firewall rules. It's the horizon option, and we use it all the time.
http://wiki.mikrotik.com/wiki/Manual:MP ... n_bridging
It basically says, any traffic coming into this port cannot leave another port with the same horizon value.

How JVR described the VLAN setup is correct. Assign the VLANs to the ports of the switch, whatever numbering you want to use. In a hotspot situation I usually do room numbers, or access point numbers etc. Then have a trunk port on the switch that is the uplink to your main router. Create all of your VLANs on the router and bridge all of the VLANs together. This is where the Horizon option must be used, without it the bridge will break down very quickly.

You can obviously block things over a bridge on a wireless to Ethernet connection with a MikroTik by using the firewall as well. It just all depends on your network setup and requirements.

what about disabling forwarding on the wireless link ? or is that irrelevant?

Forwarding on the wireless card says that two clients connected to the same radio cannot talk to each other over said radio, that's something different. If you have a wireless card bridged with an Ethernet port, traffic is still forwarded to the Ethernet port, and onto the rest of the network.

Hmm, if your only goal is to keep DHCP from traveling further upstream you could block it at the SXT station bridge by dropping inbound UDP 68 on the ethernet port. Anyone on the switch would still be affected by other rogue DHCP servers.

Feklar, the horizon option looks neat. I'll have to play with that - I can see how it could be a big problem solver for a lot of stuff.

There's actually an option in the RouterOS DHCP server to detect rougue DHCP servers and raise an alert and/or run a script.

http://wiki.mikrotik.com/wiki/Manual:IP ... ver#Alerts

At that point you can do all sorts of interesting things, like adding the offending IP/MAC to a blacklist, or redirecting all their requests to a webpage that says "The DHCP server on your router is misconfigured and until you fix it your packets aren't going anywhere but the bit bucket." Of course you probably want to sugar coat that some and provide intructions on how to fix the problem.

tjc: wow. literally. wow!

this feature is absolutely amazing!

it found two servers on my network instantly!!!!

a tp-link and a netgear.
but i am 100% sure i disabled those after finding them. i wonder ...

now for the scripting.
can you show us by script on how to block these two macs?

please

in the meantime i've gone and created the following by hand. please advise if its correct:

Go back to Feklar's first response.

I repaired a large apartment network that had this exact problem. vlans or port isolation in the switch is the only answer.
The SXT cannot block layer 2 traffic in the poweredge switch.
You may see no more dhcp alerts, but it is happening in the switch.

Getting the IP/mac address of the offending device will only let you seek it out - if you have managed switches.
You cannot block it handing out addresses over layer 2 in the switch by putting filters in the SXT or upstream.
In some cases you can log into the device using default un/pw and turn it off, disable dhcp, etc.

A common problem is someone has an old dsl router and wants to use it to attach PC, XBox and printer to the network.
They plug the lan into the wall and become the dhcp server for the network.

Also beware of a specific problem with broadcast storm detection when you bridge many vlans.
Certain RB switch chips will detect a storm and drop dhcp responses to Vista clients.
Vista requires a broadcast dhcp response by default. You'll see the broadcast flag in the log.
I ran into this problem on the RB450 w/IC+ chip. It doesn't seem to happen on Atheros switch chips.
Since the dhcp response is broadcast, a packet goes to each vlan.
The switch sees a storm and drops packets.

in the meantime i've gone and created the following by hand. please advise if its correct:

Code: Select all

2   ;;; rogue dhcp server
     chain=input action=drop src-mac-address=74:EA:3A:F2:AF:90 

That only blocks traffic to the router itself, not through it (for that you want the forward chain), and as reverged poiints out, it doesn't really solve the problem on the LAN side where the rogue DHCP server may hand out bogus IP assignments to your other customers. On the other hand blocking all of their WAN bound traffic may be enough to get the customers with the problem equipment to call customer support so that you can address their configuration issue.

I use the CPE as DHCP server 192.168.1.0/24 is there a way to check using http://wiki.mikrotik.com/wiki/Manual:IP ... ver#Alerts to find a rogue DHCP at a customers premises,

what shall I do
If I use Arp Replay in interface local
And I want Control my client
Arp Add automatically with bridge plz help

No one mentioned the bridge filter. Its more effective in blocking l2. Create a bridge with what ever port you want to filter on.

Create the filter on input and forward chain.