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]

Ron, thank you for this information! I have to wonder if one my original experiments would have worked if it weren't for my AP needing an upgrade. I will have to upgrade one and then take it home with me tonight, and then try to run through this again.

Another thing you mentioned which is setting off sirens in my head. You say that you can take your AP anywhere with Internet access and it works. For that to happen, you must be pointing your AP to a public IP address, correct? That may be what support is telling me. That this will only work if the AP is connecting to a public IP.

Can you tell me more about that part of your design?

• Do you have an interface on your controller with a public IP?
• Are you NAT'ting that public IP on your firewall to a controller interface with a private IP?
• Are you going into your AP settings and manually adding the public IP of the firewall for the controller address? I want to say I tried this, but as soon as the AP connected through the VPN tunnel, it would remove the public address from the list and go into the broken loop again.

[Ronald_Dvorak]

I've both setups running for ages - below the network diagram.
In both scenarios 802.1X PEAP is used with my NAC/AD and also Extreme Analytics is enabled for the bridge@AP SSID.

1) secure tunnel
In the HQ I've configured port forwarding on my Fortigate and on the AP I've configured the official internet address as the controller IP.
The only function that isn't supported in this setup is AP upgrade - a CR is open and I hope that this is added this year.

2) VPN
Also very simple - a VPN between my ASAs.
I've reduced the MTU to 1300 = my cable provider doens't support 1500 and also the VPN reduces the MTU.

Answer to your question:
- this is my lab controller and the AP is@home, I've the VPN running since V5.3 I think, I've upgraded my controller every time to the latest software and it was running with every version without a problem, right now I'm running latest v10

- the secure tunnel setup is running since the feature was released and I also use it for customer presentations - just connect the AP in the customers LAN with a DHCP and internet access and the AP will connect to my controller.

- ASA software is from 2008 🙂 v8.0.4, too lazy to upgrade, base license

-Ron

[Steve_Ballantyn]

Well, support is trying to help. But they sent me an article on how to use identifi with the controller and AP's both behind NAT, and the solution is "don't do that". Kind of reminds me of the old video on how to shave your beard like a man.

This gives me all sorts of other problems to consider. I have plenty of unused public IP addresses that I can dole out, so I wouldn't mind using one exclusively for my remote site AP's. But I can't think of a way to do that without giving up a physical port on my controller. And I would have to put my controller outside of the firewall. Not something I am really comfortable with.

But that leads me back to you, Ron. How did you get this working? If you don't mind, can you tell me a little more about your environment?

• Are you doing NAT at either end of your tunnel? In other words, each site has a public IP address, and your controller and AP's both have non-routable internal addresses?
• What did you end up setting your MTU at on the AP's? Did you have to lower it from 1500?
• What version of firmware are you running on your controller/AP's? I am running the latest 10 release myself.
• What version of firmware are you running on your Cisco ASA devices?

Also, if anyone can suggest a better way to make this work - I am all ears!! 🙂

When fooling around last night, I did find that I could turn off fragmentation altogether on my Cisco ASA's (not a good idea, but I tried it for troubleshooting). That didn't do anything to help this behavior though.

[Steve_Ballantyn]

I went ahead and opened a GTAC case last night (01190288) and I am working with an engineer on this issue. I will be sure to come back and report progress for the curious, or future victims of this problem!

Everything still leans to an MTU problem, but no amount of changing it in on the AP settings makes any difference. I have to believe that the Cisco ASA is doing something fruity with my packets. Perhaps repackaging them and changing the MTU against my will.

[Steve_Ballantyn]

Good call Ron, you were on the money with sharing that post. When I cranked up the logging to informational I found that my NEW controller (fresh from the box) was not actually getting a firmware update. It was failing for probably the same reason that everything else is bombing.

When I reconnected the AP that I had started with (already running the new firmware) it came up and connected okay and showed online.

Now I am back to my original problem!

Also following the advice of that post, I ssh'd into the AP and did a tail -f on /tmp/log/ap.log. Here is what it's repeating ...

Feb 18 20:13:24 cap: ru_discov_main_slp: Got 402 msgFeb 18 20:13:28 cap: 00268:ru_register.c:154-ru_register_finish()-sock=42, retval=0
Feb 18 20:13:28 cap: 00268:ru_register.c:355-ru_register()-Failed to Register/Authenticate with AC at 10.10.72.10
Feb 18 20:13:28 cap: Step<6>: Delay for 3000 mili seconds...
Feb 18 20:13:31 cap: STEP<6> (3/3) @ 0:21.000: Register & Authenticate with Access Controller,
Feb 18 20:13:31 cap: 00268:ru_register.c:287-ru_register()-MaxRetryCnt 1 curIpIdx 0 curIpRetryCnt 0
Feb 18 20:13:31 cap: 00268:ru_mgmt.c:2995-ru_disc_flush_m2pkts()-0 packets flushed
Feb 18 20:13:31 cap: 00268:ru_register.c:111-ru_register_finish()-Attempting to Register with AC: 10.10.72.10 KEY: 75ade6271034923c565e96115fa85df0

Looks like this problem is usually resolved by lowering the MTU on the AP to 1300. I tried that, and it didn't work. I also lowered it to 1200, still no dice.

But the moment I switch on "encrypt controller and ap", it authenticates and is connected. However - it still does not seem to work. When connecting to an SSID, I get the old' spinner of death (and no DHCP lease).

With this MTU value, do I need to change it *everywhere*? I tried lowering my MTU on the Cisco box (both internal and external) to 1400 and all hell broke loose. All my connections dropped. And once I got the VPN re-established, I was still unable to connect to a few things but it was slow and buggy. And my Cisco phones did NOT want to re-register.

Are there any other work arounds to this problem? 🙂