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.

[Ronald_Dvorak]

My AP is also connected via VPN - the only thing that could be an issue is the MTU.
Check out the 2nd entry in this post...
https://community.extremenetworks.com/extreme/topics/remote_aps_fail_to_connect_to_controller
... if you see the "Blacklist successfully sent to Wireless" log message everything is fine.

In that case (no enrypted data/control tunnel) you should see the IP from the remote site in the active AP reports page.

[Steve_Ballantyn]

I seem to be suffering from two unrelated problems.

I have deleted all traces of by B@AP VNS (roles, WLAN, etc). I have a few others VNS configurations which are all running fine at the main site.

I am at a remote site, connected via VPN. If I get a brand new AP out of the box and plug it it, it connects, gets the new firmware, reboots and then sits in "offline" status.

If I switch the AP to use "encrypt control traffic between AP & controller", is connects within a few seconds and shows online. However - it will not advertise any of the WLAN's. Even though they are applied to that AP, with the radios all set to On.

Is this something to do with the fact that I am connecting the AP through a VPN tunnel? If the AP is at a remote site and I am trying to use "bridged at AP" - what is the IP that it is using to connect to the controller? Seems like I should have a network defined for this site .... but it wouldn't make sense for a B@AP to do that. Which is probably why there is not a setting for an IP and gateway for a Network type of B@AP.

Perhaps I need to define a route somewhere?

[Steve_Ballantyn]

Hello Ron, the role and VNS looks okay. It was all working before I picked up the AP and brought it here. 😞

If I plug a client into the same port (my laptop) it works just fine.

Also, I just noticed that my AP shows as "offline" when looking at the dashboard on the home menu. It has an IP address from the local site, and the controller can reach it. And it updated the firmware out of the box. So why would it be "offline"? Strange!

[Ronald_Dvorak]

I've also only the base license installed - here my VLAN config - not sure why I haven't used VLAN#1 but that shouldn't be the problem.

!interface Vlan1
no nameif
no security-level
no ip address
!
interface Vlan2
nameif outside
security-level 0
ip address 192.168.0.254 255.255.255.0
!
interface Vlan3
nameif inside
security-level 100
ip address 172.24.24.254 255.255.255.0

#################################

Have you checked the role and VNS config and in the report whether the client get the right role.
So if you connect a wired client to the same port as the AP it works ?

[Steve_Ballantyn]

Hello Ronald,

I only have a VLAN 1 and 2, and while I can create a VLAN 3, I cannot "name it". I am on a basic license, and I get this message: "ERROR: This license does not allow configuring more than 2 interfaces withnameif and without a "no forward" command on this interface or on 1 interface(s) with nameif already configured."

My VLAN 1 is named "inside", so shouldn't this work on my VLAN 1? Or - is my problem this "native VLAN" and then does moving it to something else fix the untagged packets?