02-04-2010 07:13 PM
I am still getting my feet wet with the Airwave and the Aruba interface and feature set - so I hope this isn't too amateur hour of a question.
I've been working on an issue that happens on our campus-wide wireless network. I'm able to log into MSN Messenger on Vista and 7 when I'm connected to an Open network, but I'm not able to when I'm connected to a 802.1x WPA2-Enterprise network. I have checked the firewall rules, access lists, and our radius server and I can not find a reason in our non-Aruba infrastructure.
I'd like to drill down into the ArubaOS to figure out if there's a firewall setting, but I'm not sure where to look. Any help on this issue would be greatly appreciated.
02-04-2010 08:26 PM
Are the two networks one in the same or are talking about being connected to distinctly different networks?
What firewall rules are being applied to your authenticated role?
Does this work with Windows XP?
There are a lot of factors that could potentially play a role in your issue. It could be a proxy server on your enterprise network that could be blocking your traffic. MSN Messenger uses TCP 80, 443, 1863 and other depending on the features that you wish to ultize (Video, Voice, FileSharing). However, I am not positive whether the application is proxy aware or if it must be configured in the settings.
Hope this gets you started in the right direction.
02-04-2010 10:46 PM
If so, when you connect to the open network, you'll fall into the initial role and the policies defined for that. In the 802.1x network, after you authenticate, you'll fall into its default role and be subjected to its policies. Check your AAA profile settings in the VAP profile to see what's what with that.
02-05-2010 02:40 PM
I have heard that it doesn't work with Windows XP, but I haven't personally verified that. It does work on an Ethernet connection. So there is something about the 802.1x network that is different.
That is correct, the open and the 802.1x SSIDs are served by an Aruba infrastructure. The 802.1x infrastructure uses Windows 2k8R2's RADIUS implementation called NPS.
I didn't get a chance to take a look at this issue today - snow is burying the mid-Atlantic region. I'll post an update on Monday and start poking around the Authenticated Roles section. Thanks for the direction on this issue!
02-09-2010 07:14 AM
If traffic is being denied, there will be a "D" flag to the right of the session. Because of the variables involved, it's worth first identifying that your problem is at the controller and not something else.
If it is, I definitely think looking at the derived user-roles (as Mike suggested) for your open and dot1x implementations is the correct next step.
Ryan Holland, ACDX #1 ACMX #1
The Ohio State University
02-11-2010 01:30 PM
Thanks for helping me with this issue. Now that the snowpocalypse has finally ended, I have more time to work on this again.
I ran the "show datapath session table
I then figured out which AAA profile corresponded with which SSIDs. As you stated, they were different.
I then assigned the exact same "Initial Role" to the 802.1x SSID as the open SSID. Next, I set the "802.1X Authentication Default Role" to one that was "allowall" with a rule of any:any, permit.
Unfortunately, this did not work. Any suggestions on my next troubleshooting steps?
Thanks for all your help! Going through this has really increased my confidence with Aruba.
02-11-2010 02:36 PM
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base
Validated Reference Design Guides : http://community.arubanetworks.com/t5/Validated-Reference-Design/tkb-p/Aruba-VRDs
02-11-2010 02:45 PM
It would also be good to confirm that the user with the blocked chat session is actually connected, I assume that they can surf the web, etc. correct? It sounds like you've created the role correctly, you might try a 'show user
Also, I wasn't clear on your comment that 'it doesn't work with XP', what did you hear didn't work? If it 802.1X and WPA2 work with XP, you do need to have service pack 3 or the hotfix installed for the functionality, otherwise it works fine.
Director, Strategic Account Solutions
02-12-2010 01:26 PM
I checked and there are different VLANs for each of the SSIDs. I checked the router and there are no access lists or firewall settings applied to either of the VLANs.
Sorry about the vague XP comment. I have personally verified that Microsoft Messenger on Vista and Windows 7 will not connect to the 802.1x network. A student also told me that they can not connect to Windows Messenger on Windows XP.
I ran the "show user name
Here's the firewall rule for the authenticated user role:
allowall - any: any: permit: Low
I ran Wireshark on the two connections and there was definitely a discrepancy. Is there a way to check at the packet level on the controller or the radio?
Thanks for the continued help!
02-12-2010 05:09 PM
As for packet levels, you can actually mirror the packet flows to a sniffer using a firewall policy. I would highly recommend creating a separate fore for this, otherwise you're going to flood your sniffer with traffic. Place just your test user in that role and then launch your MSN session. The config should look something like:
ip access-list session "mirror"
any any any permit mirror queue low
access-list session "mirror" position 1
firewall session-mirror-destination ip-address 10.1.1.10
firewall session-mirror-destination port 1/0
Obviously you'll want to change the ports and IP to match up with your sniffer. You can change the user role from the CLI with:
Hope that helps,
Director, Strategic Account Solutions