Friday, March 11, 2011

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

13 comments:

  1. Although 1.1.1.1 works, it's considered poor form to utilize any address space which has not been allocated to you or sourced from a private range. If, as you suggest, the address is more or less arbitrary, why not change it to an unused address in a valid range?

    ReplyDelete
  2. I've heard a few people claim the 'new recommendation' but that's not stated in any official documentation I've seen from Cisco and infact, as recently as the 7.0 config guide, they still reference 1.1.1.1 as an example address. Do you have any current documentation from Cisco on this?
    -Sam

    ReplyDelete
  3. Andrew, do you have any recommendations to move from the 1.1.1.1 address to a new address?

    ReplyDelete
  4. Hi Jeremy - I agree 100% with your assessment, a public IP not assigned to the company should be avoided. Unfortunately, many if not most organizations simply followed Cisco's poorly documented examples which all use the 1-block address. A more appropriate configuration should use an unused internal address or separate private address that is not in use in the network.

    Sam - Cisco's documentation has not been updated. They should do so, especially given their own advice to use a different address.

    Tom - I would recommend using the 192.0.2.1 address since it is unlikely to conflict with anything internal or external to the organization since it is reserved as a Test-Net range.

    Andrew

    ReplyDelete
  5. Nice.

    How were you able to view the encapsulated packets?

    ReplyDelete
  6. The encapsulated LWAPP and CAPWAP packets are decoded automatically in newer versions of Wireshark. Simply ensure that the protocols are enabled in the protocol decoder / dissector configuration section.

    ReplyDelete
  7. Hey there, a great blog !

    I have thought about this usage on 1.1.1.1 address which I agree that is outdated.
    I actually had an interesting idea. Many have anchor controllers on DMZ and guest access isolated only to access internet from there.

    Now the problem with reverse DNS lookup from guests on the splash page always renders that address and certificate (if locally generated like default) untrusted and therefore guests get the https error caused by the unknown pki certificate. This can be solved by DNS internally but not everybody likes to give your guests access to your internal DNS or set up a seperate DNS server on the DMZ just to fix this one issue.

    My idea is to buy a registered web certificate (for your DMZ anchor controller) and tie a registered internet ip addresss to a hostname only meant for the virtual web page IP.
    That is registering in your internet dns a name of guests.company.com

    Yes this would mean all WLC's of the same Mobility domain/group would use this address too, but as you explained it is not a security risk and this address isn´t used for anything else on the Internet (we have to make sure of course) This automatically makes outside Internet DNS reverse lookup work perfectly! and thus no cert error for guests.

    Plan B if you don´t have the luxury to change the virtual IP, would be a static dns trick in the Cisco ASA boxes (for example) to static nat dns queries for 1.1.1.1 as 213.20.20.20 for example. But my solution is more simple since it doesn´t require anything but a outside Internet DNS access for the guests.

    ReplyDelete
  8. Hi Kristjan,
    The scenario that you proposed is in use in many organizations and works great, just as you described. The purchase of a public web certificate tied to a corporate owned domain suffix will work for guests who are pointed to either public DNS or a separate DMZ DNS server, as long as the organization owns the domain name they can publish a DNS host record that matches the web certificate. This can actually be done with any IP address, but if using external public DNS then an valid IP address owned by the organization / autonomous system (AS) is highly recommended.

    I would not recommend using the DNS re-write feature of a firewall such as the ASA because this adds unnecessary complexity and could result in mis-configuration in the future.

    Great thinking, you were correct in coming to this solution!

    Cheers,
    Andrew

    ReplyDelete
  9. Andrew,

    I'd first echo other peoples thanks for an informative summary of how the system works but I do have an additional query: when the WLC alters the DHCP server response to change the server ID it changes the packet header as well - obviously the source IP is 1.1.1.1 but where does the source MAC address come from? The MAC address doesn't appear to be any of the burned in addresses used on any of our controllers, and it's not the mac shown from "show interface detailed virtual" either so I'm a bit lost as to what it being used.

    ReplyDelete
  10. Hi Alan,
    I am not sure which MAC address is used. Please share your findings if you discover the source.

    Thanks,
    Andrew

    ReplyDelete
  11. Andrew - a problem with using 192.0.2.1 TEST-NET as your virtual is that no public certificate authority will sign this; if you want a valid Web-Auth Certificate on your controller - I know this, because I have tried and failed - this is because this address is an RFC3330 special use address intended by IANA soley for use in documentation.

    ReplyDelete
  12. Hi Damian,
    Public certificates do not involve the IP addressing space being used. Certificates are tied to the Common Name (CN) or Subject Alternative Name (SAN), which is dependent on DNS resolution of that name to an IP address. So you can tie a public certificate to any IP address you want through DNS.

    This is not a problem if the intended scope of use is internal to a private organization only. An example would be a guest network. The internal DNS servers administered by the organization can resolve the CN to a private IP address (RFC 1918 or 3330). I have done this successfully in production environments.

    If DNS is hosted by an external party or service provider, then their policies may restrict use of private IP addresses for external public resolution. You would have to check the specific provider policy.

    As a best-practice, I have adopted the following approach based on intended use:

    - Internal DNS resolution only, go ahead and use a private address and publish a DNS record for it that is only resolvable internally within the organization.

    - External use of any fashion, then use a public IP address assigned to your organization or Autonomous System (AS) and publish a DNS record for it that is publicly resolvable. This method is preferred for public guest networks, public hotspots, etc. where DNS resolution must be available publicly based on the network architecture and design.

    Cheers,
    Andrew

    ReplyDelete
  13. In the past I have looked at the options Andrew mentions above. The customer was using their ISPs DNS server for name resolution and the ISP also hosted the customers domain. I asked the ISPs 'DNS guy' to assign guest.company.com to what private IP I was using as the virtual IP (192.168.254.1 typically) and he was all too happy. From my reading at the time, it may break some RFCs but meh.. the only clients resolving it that matter are internal to the customer. Internal DNS resolution and using a public IP were not great options in this case.

    ReplyDelete