CloudFlare recently launched a set of public DNS servers that emphasize privacy and performance for all internet users.
Their new anycasted DNS service allows for interested users to point their internet-connected devices to CloudFlare’s infrastructure as a DNS resolver, replacing or augmenting services from their ISP.
CloudFlare is using IP addresses 1.1.1.1 and 1.0.0.1 as the primary and secondary IPv4 addresses. With vanity addresses like these, coupled with free privacy and performance benefits, we expect the service to become very popular among system administrators.
These specific IP addresses have the numerical appeal of being easy to remember—but there’s one major problem with them: They’re already being used in private networks today.
That means CloudFlare’s new service can create unintended headaches for IT administrators and managed service providers.
Issues with private vs public address space
In order for bits carrying our requests and information to know where to be routed, they need an address to travel to: these are IP addresses.
IP addresses can be categorized as either public or private addresses. (There are exceptions but to keep things simple, let’s stick with public and private for now).
In 1996, the Network Working Group mandated in RFC1918 that certain address ranges (10.0.0.0/8, 192.168.0.0/16, and 172.16.0.0/16) be reserved for use as private addresses. That’s because address space limitations mean every single device can’t have a public IP address.
So system administrators most commonly configure their network equipment such as switches, routers, and firewalls to hand out IP addresses from one of these RFC1918 address spaces to their clients.
In turn, any requests going to a public destination on the internet are translated from private to public network address space using network address translation (NAT).
While the 1.0.0.0/8 address range has always been considered public, both network equipment vendors and system administrators have gotten into the poor habit of using IP addresses within this range for private use.
Depending on the configuration of your network equipment, there could be one or more things your team needs to address address because of CloudFlare’s new DNS service.
To emphasize: these problems aren’t new. But with the launch of a free, consumer-friendly service for a protocol that’s critical for the internet to work, issues may surface more prominently than before.
Here are some of our findings this week as we’ve analyzed the data and read reports from across the web.
Affected: Cisco wireless LAN controllers
If you’re using Cisco Aironet wireless LAN controllers and access points, you’ll want to review your device configurations. Cisco’s default documentation and configuration samples use 1.1.1.1 as the captive portal IP—something that would have worked rather reliably up until now.
But with routes to 1.1.1.1 existing once more within the global internet routing table, your perimeter firewall or router may forward guest users’ captive portal requests onto CloudFlare instead of your wireless LAN controller.
Affected: High availability cluster shared IP addresses
When you configure devices like firewalls to be in a high availability (HA) pair, you’ll typically give each of them:
- A unique IP address to differentiate them, and
- A shared address they monitor to service requests from downstream devices.
Regrettably, sysadmins commonly use the 1.0.0.0/24 and 1.1.1.0/24 address space for these purposes.
Affected: ISP modems and gateways
AT&T customers within this DSLReports thread say some DSL modems are routing requests for 1.1.1.1 back to the LAN interface, effectively blocking the forwarding of these packets from the internet. In large quantities, this could cause a denial of service against the modem.
Recommendations for dealing with the CloudFlare announcement
We recommend you be proactive in investigating whether issues can arise on the networks you manage because of the CloudFlare announcement.
- Audit each of your client networks to find devices that may be using one of the affected IP addresses, or a variant. (If you’re an Auvik partner, we can help you with this. See the note at the bottom of the article.)
- If you see any devices with the affected IP addresses, determine an appropriate new IP addressing scheme based on the application the CloudFlare IPs are currently servicing.
- Define a method of procedure (MOP) for implementing the addressing changes. Ideally, you’ll be testing this MOP within a lab environment that mimics production. But if that’s not available, it’s critical you have a rollback procedure properly identified to minimize client downtime.
- Schedule a maintenance window with your client(s), and implement the proposed changes.
- Document the changes you’ve made to your clients’ networks.
- Update any configuration templates or best practices documents you maintain internally to state that public IP address ranges should not be used for private network applications. It would also make sense to:
- Circulate the updates to all technical members of staff that may have a role in designing or supporting a network in the future.
- Ensure such documents are reviewed by all new personnel joining the team as part of your onboarding curriculum.
Auvik can help you track down poorly configured IP addresses
If you’re a current Auvik partner, we can help you run a report on which network devices are configured with the affected IP addresses. Simply enable read-only support access from your MSP dashboard, then send an email to support@auvik.com requesting a copy of your personalized report.
If you’re not yet an Auvik partner, contact sales@auvik.com or click the Request a Free Trial button from the Auvik home page to talk to us about how we can help.
The post Why CloudFlare’s Latest Product Launch May Pose a Risk to Your Clients’ Networks appeared first on Auvik Networks.