Bridged@AP connected client cannot obtain DHCP address from the local Cisco ASA 5505?

[Steve_Ballantyn]

I have a Cisco ASA 5505 with an Extreme 3825i plugged into it. I am pushing a VNS with a WLAN which requires zero authentication (trying to start off EASY). Right now I have it set in Bridged@AP mode, as I am trying to establish a guest network at the local site level.

I can see the SSID, and join it just fine, but I can never obtain a DHCP address. I am sort of at a loss here. There doesn't really seem to be much to configure? I can choose to tag/untag the port. But this is a Cisco ASA 5505 and there are only two VLAN's I am permitted to use, which is '1' for the local net, and '2' for the external NIC. I have tried setting it to tagged and untagged, but to no avail. When I run a packet capture while connecting, it appears that I am sending discover's to an empty room.

When I plug into the wired network - I get an address right away. I have determined that there are no licensing problems or filters on the ASA. But I have to wonder if it's just ignoring this traffic for some reason.

[Steve_Ballantyn]

I will try to explain, hopefully this makes some sense. In this example, you have a headquarters with a controller and a remote site with an AP. The controller is booting up at the remote site and grabbing an IP from the local network (192.168.1.x).

Step #1 (don't skip this) - Plug in your AP at your headquarter site and let it find the controller, and update it's firmware. You cannot upgrade the firmware remotely. Then, take it to your remote site.

Step #2 - Now, the AP needs to reach out and look for a controller. There are several methods of "finding" a controller. The least elegant, but easy to implement at a remote site, is to drop a DNS host entry at your firewall for "controller" which points to the *PUBLIC IP* of your remote headquarter firewall. If you know the IP that your AP picked up, you can also SSH into the AP and set the controller IP manually. At a shell prompt, you would enter:
cset authipaddr 76.54.32.21capplycsaverebootStep #3 - Set up a IP forward on your headquarters firewall for all of the Extreme Networks ports. Also - you should create a rule on your firewall so that it is only accepting this traffic from your remote site(s) (to prevent abuse from strangers flooding your controller with garbage UDP packets). NOTE: You will find in this Extreme GTAC that you cannot NAT both your controller and your AP's. But that is not really what we are doing here. To the AP, it's controller is a public IP address.

Step #4 - If you need to encrypt traffic (probably a good idea given this design) you should set the AP up that way. To do that: Click on the AP tab in your controller admin pages. Then All. Then select the AP from the list. Then click the Advanced button. Then click the Secure Tunnel drop-down and change it to Encrypt control & data.

Step #5 - Make sure you have a default route to the Internet for your Extreme controller. This is what threw me off. In the picture above, 172.17.1.x has access to the Internet. And the interface on the Extreme controller does too. But it won't route Internet traffic out through that interface without your say so. Click Controller tab > Network > Routing protocols. Click New. It should be something like:
Dest Addr: 0.0.0.0
Subnet Mask: 0.0.0.0
Gateway: 172.17.1.1

When you click Save your Extreme Controller will show what interface it's using based on what you provided.

Step #6 - Profit???

If you decided to do a split-VNS sort of thing, it gets a little more complicated. But the gist of it is that your Non Authenticated is using a "bridged at controller" while your Authenticated uses "bridged at AP". The effect is that your visitor gets a splash page from the controller, clicks accept, and then after a short delay, they are connected at the local site.

Remember that you need to set up policies, especially for a guest setup. For non-Auth, they should only be able to access the controller. For Auth, they should only be able to access the gateway at the remote site - but not any of the local hosts on that network!

I am sure I am leaving out some details here --- but hopefully this is helpful to you.

[Steve_Ballantyn]

Hello Martin, are you attempting to do a "split topology" like I did? The only reason you would do something like that is if you want to have a Guest Splash (or other captive portal) but then channel the users Internet access out through the remote sites Internet. The alternative is to drag all of the traffic through the AP and the controllers WASSP conversations, which for me would be passing through a VPN connection (sloooowwwww!!!).

Can you tell us a little about your environment? What type of firewall do you have at your headquarters (where your controller is), and what type of firewall do you have at your remote office?

Probably the best way to explain this would be for me to draw a picture. I will work on that and post it shortly.

[Ronald_Dvorak]

Hi Steve,

I've also an AP on a ASA5505 on the internal VLAN = the ASA provides DHCP service to the WLAN clients...

Cisco ASA:
interface Vlan3 nameif inside
security-level 100
!
ip address 172.24.24.254 255.255.255.0
!
interface Ethernet0/7
switchport access vlan 3
!
dhcpd address 172.24.24.75-172.24.24.106 inside
dhcpd dns 8.8.8.8 interface inside
dhcpd enable inside
!
######################

On the WLAN controller I use the default bridge@AP topology - so the only thing left is the correct role configuration - check in the report whether the client get the right one.

Here my role...contain to the bridge@AP topology (the VLAN is untagged, 4093 is only used as an internal reference).

[Ryan_Mathews]

Good stuff Steve. Glad you persevered!

Appreciate you relying on the Hub Community to help you sort this out.

[Steve_Ballantyn]

I HAVE SOLVED THE RIDDLE.
Today I was attacking this from a switching/routing perspective. It didn't appear that anything was being blocked. And even if it was, I would at least see the controller *TRY* to send something out to the public IP of my remote access point.

That's when it hit me. Default route. Duh.

I went into the Controller > Network > Routing Protocols and added a default route. In my case it was:
Destination: 0.0.0.0
Subnet mask: 0.0.0.0
Gateway: 10.10.72.1
Override dynamic routes = checked

Instantly, the AP joined the controller and began pulling the VNS down.

Ron, thank you for all of your advice. I really appreciate all of the effort you put forth in helping me out with this. Hopefully this long running topic will help other lost souls like myself in the future.

Also - thanks to Craig in support. He has been feeding me tips, GTAC articles, and other such advice throughout this ugly troubleshooting process.