What is Rogue DHCP? How to prevent it on WISPs With Mikrotik

Rogue DHCP servers are actually DHCP servers which are not set up correctly or works on the network unwittingly or without permission and control of the network administrator. Most of such servers are used for malicious activities and network attacks. These servers can disrupt systems performance particularly network clients, even though they don’t perform destructive operations and are created just randomly on the network. If there are such DHCP servers in the network, clients use this service and get an IP configuration which is not related to current network or has an incorrect setting. For example, they are given different gateway or DNS address compared to the real network environment. By setting up such DHCP server, a hacker can introduce himself to a client as a service provider and sniff all traffics generated by this client.

Consider the following scenario for better understanding:

Figure 1: WISP
In this scenario, there is a WISP intends to connect its client to PPPoE Server using two APs. The client is connected to APs and the internet using Bridge and PPPoE connection modes exist in the access point, respectively. Generally, each client has its internal network and receives the IP address from DHCP server in AP.

A bridge is a layer 2 connection, like switch it can be used to connect two or more similar networks (Ethernet) and transmit frames between them. From this point of view, they are not different and considered equivalent by network experts. The only distinctive thing between them is that switch can connect two different networks (wireless and Ethernet), transfer, convert and forward frames.
For better understanding, first consider the operation of DHCP protocol.

Figure 2: DHCP operation
The operation of DHCP is divided into four basic steps (DORA):

  • DHCP Discovery
  • DHCP Offer
  • DHCP Request
  • DHCP Acknowledgement

DHCP discovery

The client broadcasts messages on the network subnet using the destination address or the specific subnet broadcast address. A DHCP client may also request its last-known IP address. If the client remains connected to the same network, the server may grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server denies the request, causing the client to issue a new request. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client to expire the request and ask for a new IP address.
Below is an example. HTYPE is set to 1 to specify that the medium used is [Only registered and activated users can see links. ], HLEN is set to 6 because an ethernet address (MAC address) is 6 octets long. The CHADDR is set to the MAC address used by the client. Some options are set as well.
DHCP offer

When a DHCP server receives a DHCPDISCOVER message from a client, which is an IP address lease request, the server reserves an IP address for the client and makes a lease offer by sending a DHCPOFFER message to the client. This message contains the client's MAC address, the IP address that the server is offering, the subnet mask, the lease duration, and the IP address of the DHCP server making the offer.
The server determines the configuration based on the client's hardware address as specified in the CHADDR (client hardware address) field. Here the server,, specifies the client's IP address in the YIADDR (your IP address) field.
DHCP request

In response to the DHCP offer, the client replies with a DHCP request, broadcast to the server,[Only registered and activated users can see links. ] requesting the offered address. A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer. Based on required server identification option in the request and broadcast messaging, servers are informed whose offer the client has accepted.[Only registered and activated users can see links. ]:Section 3.1, Item 3 When other DHCP servers receive this message, they withdraw any offers that they might have made to the client and return the offered address to the pool of available addresses.
DHCP acknowledgement

When the DHCP server receives the DHCPREQUEST message from the client, the configuration process enters its final phase. The acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the IP configuration process is completed.
The protocol expects the DHCP client to configure its network interface with the negotiated parameters.
After the client obtains an IP address, it should probe the newly received address[Only registered and activated users can see links. ] (e.g. with ARP [Only registered and activated users can see links. ]) to prevent address conflicts caused by overlapping address pools of DHCP servers.
Suppose we have a DHCP server on Bridge interface of one of the client’s Radio. What happens?
Look at following figure:

Figure 3: DHCP Offer
A DHCP Offer is passed through Bridge and forwarded to all destinations on both APs, each node in network which is set up on DHCP client receives this packet and reply it and forward DHCP Request toward DHCP server.

Figure 4: DHCP Request
DHCP Server sends DHCP ACK in response to DHCP Request packet which contains DNS, Gateway, IP, ….

Figure 5: DHCP ACK
By changing Gateway, DNS and IP Address, we can say that our network is disrupted, it is called Roge DHCP which happens intentionally or unintentionally by clients and insufficient accuracy in AP configuring by WISP.
What should be done to prevent this problem:

  1. Preventing intra-connection between AP clients

To do this, go to AP's network card settings and perform following stages:

Figure 6: AP setting
And deactivate Default Forward option.

Figure 7: AP setting
If the above steps pass correctly, consequently this AP’s clients cannot interconnect with each other anymore.

  1. Preventing inter-connection between AP1 clients and AP2 clients

It is possible using two approaches:

  • Compartmentalize broadcast of each AP using Vlan

In this approach, we connect APs to PPPoE server using Management Switch and group each of the switch ports which are connected to APs to Unique Broadcast. With this, the commons between APs are separated and clients cannot send packet to other APs.

  • Using Bridge Filter Rule

Note that we provide internet service for clients based on PPPoE, therefore, it is not necessary for other protocols except bridge to be passed through PPPoE. In order to prevent other protocols, the following codes are typed in router terminal:

/interface bridge filter
add action=accept chain=forward in-interface=wlan1 in-interface-list=all \
add action=accept chain=forward in-interface=wlan1 in-interface-list=all \
add action=drop chain=forward in-interface=wlan1 in-interface-list=all

Or the following steps are done:

Figure 8: bridge Filter

Figure 9: bridge Filter

Figure 10: bridge Filter
If the above steps pass correctly, no client can send protocol other than PPPoE to AP anymore.
Azizollah Bandzan | MikroTik Certified Academy Trainer/ Consultant
[Only registered and activated users can see links. ]