Many wireless engineers know that having a lightweight AP join up to a controller across a NAT requires some extra configuration. But many don’t understand why it needs the configuration. This article will talk about what the NAT is, why it causes a problem for the normal join process, and what the configuration changes do to make things work.
What is NAT and where do we see it in the wireless world?
NAT stands for Network Address Translation, and it does pretty much what the name implies. It translates addresses from their original values to something new. Let’s take a look at a classic wireless example.
Let’s say I have an office Extend AP (OEAP) in my house, and I want it to join the WLC in my company’s DMZ. But I don’t want to actually configure a public IP on my WLC. This is where the NAT comes into play.
In the image above, the OEAP talks through the firewall in order to talk to the DMZ WLC. In order for the AP to talk to the WLC, it has to target a public IP because it needs to communicate across the Internet. So if the WLC itself doesn’t have a public IP, we configure a public IP on the firewall for the OEAP to target. When the traffic from the OEAP reaches the firewall on the specified IP, the firewall will rewrite the destination IP address of the packet with the private IP address of the WLC and forward the packet towards the WLC. In the reverse direction, as the WLC sends packets to the OEAP, the firewall rewrites the source IP so that it looks like it’s coming from the public IP when it arrives at the OEAP. So without the OEAP being aware of it, it’s actually communicating to a private IP even though it looks like it’s talking to a public IP. This allows the WLC to use a private IP while still talking to APs out on the Internet.
Why does this cause a problem for my OEAP?
We can see that the OEAP and the WLC can talk just fine across this NAT. So what’s the problem? It has to do with how the discovery and join processes work.
The first thing that must happen is that the OEAP must discover the WLC using this public NAT’ed IP. Typically the OEAP would be configured such that the DMZ WLC is its primary WLC, referencing the public IP address. That means that the OEAP sends a discovery request to the public IP. The discovery request crosses the NAT and arrives at the management interface of the WLC. The WLC then sends back a discovery response to the OEAP, which makes it back to the OEAP. So far so good. But now we are going to have a problem.
The next steps will be that the OEAP will send a join request to the AP Manager interface of the WLC. But what IP address will it send the join request to? Part of the information in discovery response that the WLC sent the OEAP is the IP address of an AP Manager interface to send the join request to. This is the actual IP configured on the AP manager interface itself. This IP address is a private IP address. So when the OEAP sends its join request, it sends it to the private IP address instead of the public NAT’ed IP address. Thus, the request never traverses the Internet and never makes it to the WLC. So the OEAP never joins the WLC.
How can we make this work?
Assuming the WLC model and code level supports it, every AP manager interface has a checkbox to enable NAT support. Once you check the box, you can type in the public IP address that corresponds to the private IP address of the AP Manager as configured on the NAT on the firewall. Once you configure this setting, it alters the behavior of the discovery responses. Now when the WLC sends a discovery response, it uses the public NAT IP address as the address of the AP Manager interface. So the OEAP learns that it should send the join request to the public IP. Thus, the join request gets to the firewall and the firewall NATs it and forwards it on to the WLC’s AP manager interface.
Design considerations when using NAT
Here are some things to keep in mind when you start to support AP joins across a NAT.
- The NAT should be a 1-to-1 NAT where you have a unique public IP address for each AP Manager interface IP address.
- If you have multiple AP Managers on your DMZ WLC, you will want to enable NAT on all of them. Otherwise, you will have instances where the OEAPs are learning private IPs in the discovery responses.
- Once you enable NAT on an AP Manager interface, ALL APs must join across this NAT. So by default, you typically won’t have APs both on the Internet and on the internal corporate network joining the same WLC because the internal APs typically won’t be able to target the public IP address and use the NAT.
- You can get around this limitation starting in 7.0.220.0 code with the CLI command “config network ap-discovery nat-ip-only disable”.
- You don’t actually have to use an AP in OEAP mode to join across a NAT. But if you use a different mode, I’d be sure to enable DTLS encryption if there are any centrally switched WLANs to protect your client data traffic from being snooped on.
