Explaining DHCP Server 1.1.1.1

Often times, I am asked by other network engineering and security teams to investigate a potential problem or security issue with the corporate wireless network because clients are obtaining a DHCP lease from an apparently non-existent server with an IP address of 1.1.1.1.

I calmly explain to them that this is expected behavior and is nothing to worry about. However, the conversation usually does not stop there. This only seems to prompt more questions because my answer sounds, on its face, to go against every "preconception" network engineers hold to be true. In order to satisfy their curiosity, it's necessary to explain in a bit more depth how DHCP proxy and web authentication function in the Airespace wireless world (now Cisco Unified Wireless Network).

First, let's level-set the expectations:

• DHCP server 1.1.1.1 IS perfectly valid for wireless clients
• It is NOT a mis-configuration
• It is NOT a security issue or risk
• It will NOT cause an operational or performance issue for wireless clients
• The server address CAN be changed (and is now recommended, more on that below)
• DHCP proxy functionality on the controller MAY be changed, but most times should NOT be

Here is what is going on:

The wireless LAN controller perform DHCP proxy functions using an internal non-routable interface, called the virtual interface. Almost all public documentation by Airespace and Cisco show examples assigning the virtual interface an IP address of 1.1.1.1, which has become the de-facto standard for most deployments. The virtual interface is not attached to any physical ports, is not routable across the network, and is only used by the WLC internally.

DHCP proxy is useful for wireless client roaming in mobility anchoring scenarios to aid faster network connection re-establishment, particularly when performing Layer 3 A-Symmetric mobility tunneling to prevent the client from attempting to get an IP address in the new subnet. Instead, traffic tunneling between controllers allows the client to maintain their original IP address.

The WLC intercepts client DHCP discovery packets, inserts it's own IP address configured on the egress interface into the relay agent field, and unicasts the DHCP packet to the configured DHCP server. Here is an example packet capture from the wired port on a controller:

Here we see that packet #1 was the client DHCP broadcast discovery (carried inside the LWAPP tunnel from the AP to WLC), and packet #2 is the WLC relaying the packet to the configured DHCP server, which in this case is the subnet gateway address. Notice the relay agent information inserted by the controller.

Note - packet numbers 1, 4, 5, and 8 are all inside the LWAPP/CAPWAP tunnel between the AP and controller.

Once the server response is received by the WLC in packet #3, it modifies the DHCP offer and changes the DHCP server ID to the virtual interface address, as shown in packet #4 below.

Clients on the wireless network will perceive their address to be assigned by the server at 1.1.1.1 and will send all renewal requests to this address. This is perfectly normal and acceptable.

It is also important to note that web authentication uses the WLC virtual interface address, and will be seen during web login as the captive portal redirect page.

Changing the virtual interface IP address is now recommended because the 1-block (1.0.0.0/8) was assigned by the IANA to APNIC in January 2010, and is now a valid Internet address. Therefore, wireless clients attempting to reach a valid host at 1.1.1.1 on the Internet would not be able to successfully unless the WLC virtual interface has been configured to use a different address. It is now recommended to use an RFC1918 private address or an RFC3330 Test-Net address (such as 192.0.2.1/32).

To summarize, the DHCP server address of 1.1.1.1 is perfectly valid for wireless local area networks and does not cause operational, performance, or security concerns when used.

Cheers,
Andrew