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

  • 0
  • 1
  • Question
  • Updated 2 years ago
  • Answered
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.
Photo of Steve Ballantyne

Steve Ballantyne

  • 5,806 Points 5k badge 2x thumb

Posted 3 years ago

  • 0
  • 1
Photo of Ronald Dvorak

Ronald Dvorak, Embassador

  • 50,124 Points 50k badge 2x thumb
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).

Photo of Ronald Dvorak

Ronald Dvorak, Embassador

  • 50,124 Points 50k badge 2x thumb
Is that now via the ASA VPN or not ?
If you use VPN does a ping from the AP console to the internal controller IP work.

So to the IPs - is that correct...
controller internal = 10.10.72.10
controller ext = 74.219.x.x
AP external = 65.186.x.x

What's your MTU ? Set it to 1300 on the controller and reboot the AP please.
I get the same AP log messages with my MTU on 1500 (which doesn't work @home on my cable modem/VPN setup).
Photo of Ronald Dvorak

Ronald Dvorak, Embassador

  • 50,124 Points 50k badge 2x thumb
You'd also try with your PC @home to ping the internal controller IP and set the "don't fragment bit" to check the max. MTU on the link.

Here mine.. as you'd see I doesn't work with 1500, 1400, 1300 but is OK with 1250.
Even the ping show that 1300 isn't working I use that value on my AP because as as far as I'd remeber the windows ping takes the buffer size (1300) and adds the header = a larger frame is send.

Photo of Steve Ballantyne

Steve Ballantyne

  • 5,806 Points 5k badge 2x thumb
Hello Ron, if I set up VPN to 10.10.72.10, I can ping it with packets up to 1398 (1399 fails). I presently have my MTU for this AP on the controller set to 1200 just to be safe. But - I have removed that VPN tunnel to prevent any confusion with the traffic.

Here is a poor man's network drawing of the setup, which confirms how you believe that it's set up.

Photo of Steve Ballantyne

Steve Ballantyne

  • 5,806 Points 5k badge 2x thumb
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.

Photo of Ryan Mathews

Ryan Mathews, Alum

  • 8,988 Points 5k badge 2x thumb
Good stuff Steve.  Glad you persevered!

Appreciate you relying on the Hub Community to help you sort this out.
Photo of Martin Perez

Martin Perez

  • 212 Points 100 badge 2x thumb
Hi , Can you help me ? I need a connection between the AP remote office and ECW across internet,  can give me more information ?, I see that you have experience in the case. Thank you.
Photo of Steve Ballantyne

Steve Ballantyne

  • 5,806 Points 5k badge 2x thumb


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.21
capply
csave
reboot
Step #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.
Photo of Martin Perez

Martin Perez

  • 212 Points 100 badge 2x thumb
Hey you are a Master! , thank you so much. Your tutorial is complete for me, now is Up the system.
Photo of Carlo Alviar

Carlo Alviar

  • 680 Points 500 badge 2x thumb
Hi Steve,

Just want to ask what port classification do i need to specify for this part of the network? From the AP going to the firewall (please see attached diagram you have provided). Do i need to setup as port 80 or port 443?

I need to specify this part for the firewall configuration.
(Edited)
Photo of Steve Ballantyne

Steve Ballantyne

  • 5,806 Points 5k badge 2x thumb
Hi Carlo, I don't have anything special defined there in my firewall config. I have a rule that allows any traffic on the inside to any destination on the outside. I think that is how most people set things up?
Photo of Carlo Alviar

Carlo Alviar

  • 680 Points 500 badge 2x thumb
Hi Steve,
I already followed the steps you taught me and its working now. The remote AP could already access the controller in HO. But when you look at the AP availability menu you cant see the AP as available.

Is it possible to control the AP in the remote site running on b@AP via the HO controller? And also instead of putting public IP in the AP is it possible to use domain name instead?