Wireless Access

Hi!

 

A couple of weeks ago, we changed an SSID in a remot office to bridge from tunnel, effectively dropping the clients on the same vlan as the AP's and wired clients are connected for that office. During the change I had contact with an end user who tested all functionality after the change of IP-addresses etc and everything worked fine.

 

After that, three clients are experiencing problems with getting an IP-address through DHCP. I can see them associated in the station-table but the client doesn't get an IP, and even more weird, when issuing "ipconfig" on the win7 laptop it reads:

 

Netmask: 169.254...

Netmask: 255.255.0.0

 

I've never seen this behaviour before. If I try to put a static IP on the client, it works fine. I've reinstalled the adapter and verified it's the latest drivers. All three affected clients are HP Laptops with Intel Centrino Advanced-N 6200 AGN NIC. If they connect to a hotspot from their phone, they get an IP-address and it works fine. I also created a new SSID with a new name and open, same issue. Also note that many other users with this same model of laptop and NIC is using the network with no issues.

 

We're running AP105's on 6.2.x

 

Any ideas what could be causing this?

 

 

Chris

That IP address is one that Windows clients usually show if there is no DHCP response.  That is quite normal.  What isn't is the fact that you're not getting an IP on the clients.  

 

Have you run out of IP addresses on the server?

Who's assigning the IP addresses ?

 

How's your user-role configured ?

That's the windows APIPA address yes, but what's strange is that it says "Netmask" in front of it when I issue ipconfig.

 

I've verified the DHCP scope, it's got plenty of available addresses and it's located at our service provider that provides MPLS line to the remote office.

 

The user role is an allowall role.

 

Authentication is WPA2 PSK.

 

Chris

If your DHCP is local then you should have the following in your user role/access list
user any any route src-nat

 

 

hmm, I'm guessing that's for split-tunnel. I want my users to end up on the default vlan, not to be source-NATed behind AP's IP.

 

Or am I misstaken?

 

Chris

Is it feasible to have the user experiencing the issue fire up Wireshark and capture the wireless interface as it connects? (I know this is a long shot)

A default VLAN configured on the VAP or on the ap system profile ?

We might be able to get wireshark running on the problematic client using wired connection and remote access.

 

The same VLAN as the access point get its IP from, it's connected to an access port on the switch. The remote branch has only one subnet locally and that's where we want to place the wireless users along with wired stations, access points and local file server. 

 

Chris

Since everything will stay local I would add that rule in there

Today we tried putting up a fresh new bridge SSID but the same error occured for the few problematic clients. We've been exercising alot of "cleaning out" of WLAN profiles using netsh interface reset commands etc. Removing features and changing parameters to the VAP and SSID profile settings. All without any success.

 

We installed wireshark and captured the exchange of the client trying to get an IP-address, the result was showing several DHCP requests going out but nothing coming back. As if it wasn't bad enough, a few more problematic clients arose when more people came back from summer vacation.

 

Any more guesses guys?

 

Tomorrow I'll involve the ISP who handles the IP-helper and DHCP server to see if they're recieving any DHCP requests and sending offers back.

 

Chris

Did you tried adding that acl rule ?

Sorry for the delayed response, yes I tried adding your suggested rule but experienced the same issue. We finally tried with an external USB NIC and that works perfectly.

 

My theory atm is that there's some cache somewhere in windows that I havn't found yet that causes this behaviour. Anyway they're getting their clients redone at this office and my guess is that after a fresh install the bridge SSID will work.

 

Frustrating not to get the bottom of the problem but I can only spend so much time on client issues :P

 

Thanx for all the input.

I am having the exact same issue except with iPads in a school.  I need to get this resolved ASAP.  The DHCP is being done on a Cisco 3750 on the Bridged Vlan at the building some iPads connect but dont get an IP address most conenct just fine though.

Hi jwoodworth90! It sounds like you´re missing the client VLAN on the trunk ports to some of your APs. Double check that you´ve got all the VLANs tagged to the APs.

 

 

I´m acctually gonna post in this bad boy thread again. I "solved" this issue by implementing a split tunnel configuration where clients get IP-adresses centrally and I route-src NAT everything destined for the local subnet, rest is tunneled. The couple of problematic clients worked fine in this configuration.

 

Today I got a call from one of the users at the site who claims she´s been having issues with the wireless all the time. After troubleshooting a little bit, I see the same "double netmask" in the ipconfig with a windows APIPA address that I explain in my first post. She claims there´s another one with the same issue but I havn't verified it yet.

 

So now with the new split-tunnel configuration there´s two new clients that experience the exact same issue as the other clients did before on the bridge configuration. 

 

I found this in the user debug log that looks kind of suspicious:

<DBUG> |authmgr|  MAC=c4:85:08:b3:0d:5d (vlan:126) Detecting Wireless-user AAA-Profile mismatch or wireless<->wired roam

 

See the full user-debug logs for one authentication try attached. I can see some worrying entries about a logon role popping in at some stages.

 

Also I´ve attached the configuration of the user-role. This gets derived from successfull 802.1X authentication per the AAA profile configuration.

 

Anyone have any ideas? Affecting 1 or 2 clients from about 20 total. We´re up to Aruba OS 6.4.2.2 now on our M3.

 

Cheers,

Chris

Is there more than one access point at this site?

 

EDIT:

 

Your main problem here is that you need to have an "any any service dhcp permit" statement at the top of your ACL.  A dhcp request from a client will only hit rule 3, because dhcp does not have a destination that matches "Except-Company".  The user will then get no ip address and then end up in the user table with a 169.00 addrexx.  Put a rule allowing dhcp at the top and see if it fixes this.

 

Split-Company-Local
---------------------
Priority  Source  Destination       Service  Application  Action         TimeRange  Log  Expired  Queue  TOS  8021P  Blacklist  Mirror  DisScan  ClassifyMedia  IPv4/6  Contract
--------  ------  -----------       -------  -----------  ------         ---------  ---  -------  -----  ---  -----  ---------  ------  -------  -------------  ------  --------
1         user    any               udp 68                deny                                    Low                                                           4
2         any     Except-Company  any                   permit                                  Low                                                           4
3         user    any               any                   route src-nat                           Low                                                           4

 

Hi Colin!

 

Yes, there are 5 AP-105:s at the site configured as remote APs and connected to local switches on access ports. 

Split-tunnel is not designed for roaming.  It is only designed for a single AP at a site.  You are better off using bridge mode, because whenever a split tunnel user roams, it is forced to reauthenticate all over again.  It is not seamless, because the firewall rules are contained within each access point and does not roam with them.  With bridge mode, if the access points are on the same vlan, it will allow roaming and transfer the client's firewall state to the next access point.  Please use bridge mode instead.

 

I understand, although bridge mode was what started this thread in the first place I´d just go back to a more widely spread version of the issue. If we can somehow pinpoint what´s causing this issue perhaps I can fix it and then revert to bridge mode again.

I was never able to get this to fully work in bridge mode and couldn't keep trying different things as it was causing lots of down time for my students.  Unfortunately I had to change it back to Tunnel but I really want to get Bridged mode working correctly.

jwoodworth90,

 

If it is important to you, please open a TAC case so they can look at it in detail to see why it would not be working in your case.

 

 

I Did and after about 4 days of not being able to figgure it out I had no chocie but to setup as tunneling so the students could actually use the newtwork. 

jwoodworth, what is your issue?  Please open a separate thread about it.

 

If you are not getting anywhere with TAC, you can have the case escalated.

 

 

I am Having the same exact issue as the Original Post.  When things slow down a little bit here i might be able to try this again and work with TAC.

This is a remote office connected through our WAN ISP, on site we have a single cisco switch setup with one single VLAN terminating in the ISPs equipment. DHCP is given by the ISP.

 

On the other end of the WAN is the customer HQ with a Palo Alto firewall connected to a mgmt zone where the controller resides. All the necessary ports for AP->Controller communication is in place.

 

The controller is connected to client-VLANs including vlan 126 where the users are getting their IP-address right now with the split tunnel configuration.

What was not working with bridge mode...dhcp?

For ~3 clients yes. Read the original post for a more detailed description of the issue.

---

@Christoffer wrote:

For ~3 clients yes. Read the original post for a more detailed description of the issue.

---

Were those the only 3 clients with the issue?

 

Colin, to my knowledge yes. Out of about 20 clients in total.

Christoffer,

 

You said the DHCP server is a router?  Is there any way to turn that off and deploy a different DHCP server that would have more diagnostic information about why ip addresses are not being received?

I believe the ISP has a windows machine for DHCP and they use IP-helpers from their CPE. Anything special I want to check I´d have to involve them for troubleshooting.

Christoffer,

 

Since it is the same 3 devices, have you tried putting those 3 devices at a different site with the bridged configuration to troubleshoot?  If it is only those three devices, those should be the focus.  

You should build a test environment with the same configuration to understand what works consistently and try to make it as close to your existing environment as possible, so we can understand where this could break.  The ISP and their DHCP server is the key to understanding what is going wrong.  You might want to schedule a window with the ISP and Aruba TAC to do some end to end testing to understand where the dhcp packets could be dropping.  I don't want to just take the ISP's word that everything is being delivered reliably and DHCP is being sent back.  You said your packet capture indicates that dhcp is not returning, we need to know where it is being dropped with genuine end-to-end testing.  That is the only comprehensive solution to this...

Ok, thanks for your input Colin. I´ll see if I can have this arranged.

Correct, Some would get DHCP and Some would not. DHCP Pools had plenty of
addresses available.
*Jeremy R. Woodworth*
*Network Supervisor*
*Mentor Public Schools*

Jeremy: is your problematic clients always the same ones or does it differ? Did you double check that you have all your client VLANs tagged to the APs running bridge mode?

All VLANS were tagged and the clients were always different.


*Jeremy R. Woodworth*
*Network Supervisor*
*Mentor Public Schools*

Ok Jeremy, your problem is something else than mine then. My problem always affects the same set of clients, hence I asume it to be some sort of client issue.

---

@jwoodworth90 wrote:
All VLANS were tagged and the clients were always different.


*Jeremy R. Woodworth*
*Network Supervisor*
*Mentor Public Schools*

---

jwoodworth90,

 

Since you do not have that setup in place, you should open a case with support when you have your setup in place, since we cannot get any specific data from your setup about what could be happening.  The factors leading to your issue could be numerous or individual, but without your setup in place, we cannot uncover anything in this thread...  On a basic level it should work and it works in many environments.  Unraveling why yours does not work requires your logs as well as a diagram of your infrastructure when your setup is in place.

---

@jwoodworth90 wrote:
Correct, Some would get DHCP and Some would not. DHCP Pools had plenty of
addresses available.
*Jeremy R. Woodworth*
*Network Supervisor*
*Mentor Public Schools*

---

jwoodworth90,

 

Please open a TAC case when you are ready to troubleshoot.  They would need to have your toplogy as well as what kind of DHCP server you are using, along with your logs.tar from your controller.

 

Is the issue that clients are not getting DHCP?

 

What is the topology and how is this site connected to the site with the controller?