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]

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.

[Ronald_Dvorak]

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.

[Ronald_Dvorak]

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).

[Steve_Ballantyn]

Hello Ron, thanks for the additional information. It really looks like I have this all set up correctly. It seems like my traffic is getting to the controller but the controller just refuses to answer back to it.

Here is what the log looks like on the AP side ...

Jan 1 00:02:59 cap: 00268:ru_register.c:323-ru_register()-Successfully Registered & Authenticated with AC at 74.219.X.XJan 1 00:02:59 cap: ACINFO: Save Binding key: dbc688087d7c285faf879551fedbfd93
Jan 1 00:02:59 cap: STEP<7> (1/5) @ 2:33.000: Software version validate,
Jan 1 00:02:59 cap: 00268:ru_mgmt.c:2995-ru_disc_flush_m2pkts()-0 packets flushed
Jan 1 00:02:59 cap: 00268:ru_sw_version_validate.c:67-wassp_ru_sw_version_validate()-s/w validate: model='AP3825i', vers='10.01.01.0129.M.00', s/n='15241161085J0000'
Jan 1 00:02:59 cap: 00268:ru_sw_version_validate.c:227-ru_sw_version_validate_finish()-Send 62 bytes data to ac 74.219.X.X
Jan 1 00:02:59 cap: 00268:ru_mgmt.c:2535-whsl_trans()-S_EDISC 145
Jan 1 00:03:01 cap: 00268:ru_mgmt.c:2535-whsl_trans()-S_EDISC 143
Jan 1 00:03:02 cap: 00268:ru_mgmt.c:2535-whsl_trans()-S_EDISC 142
Jan 1 00:03:03 cap: 00268:ru_mgmt.c:2535-whsl_trans()-S_EDISC 141
Jan 1 00:03:04 cap: 00268:ru_mgmt.c:2535-whsl_trans()-S_EDISC 140
Jan 1 00:03:05 cap: 00268:ru_mgmt.c:2535-whsl_trans()-S_EDISC 139
Jan 1 00:03:06 cap: 00268:ru_mgmt.c:2535-whsl_trans()-S_EDISC 138
Jan 1 00:03:07 cap: 00268:ru_mgmt.c:2535-whsl_trans()-S_EDISC 137
Jan 1 00:03:08 cap: 00268:ru_mgmt.c:2535-whsl_trans()-S_EDISC 136

And then here is what the controller is showing when I run a capture against this interface ...

If I perform a ping to the external IP of 65.186.X.X from the controller interface (10.10.72.10) I get replies. But it sure seems like it either a) doesn't know how to get the traffic there or b) it just doesn't *want to*.

[Ronald_Dvorak]

Diagram#1
Correct the AP has the public IP A.B.C.D configured to connect to the controller (cset authip 1 A.B.C.D).
The controller has not a public IP but I do translation/forwarding.
On the HQ firwall I've only allow to forward the ports 13910, 4500, 13907 and translate A.B.C.D to 10.12.0.1 (controller ESA port).

Check the controller GUI > AP > Bulk Configuration > AP Default Settings > Common Settings > Static Configuration
I've set it to "Learn EWC Search List from AP"
Might be that you have it set to the internal IP so the external IP get's overwritten every time the AP connects.

-Ron