09-10-2012 12:40 PM
We are currently in the midst of learning about Aruba and how to properly configure this system.
We have a 3200 Controller and several AP-105's. We are currently trying to get just one AP-105 working properly but are running into issues.
We have been able to setup a test SSID that basically extends our wired network. IP's are provided by a standalone DHCP server (not by the controller). We are not using any external authentication server at this time.
The Controller is connected to our Layer 3 switch stack. The ports are configured in a trunk mode to allow the appropriate VLAN ID's.
We are using a laptop for testing and it is able to connect to the test SSID and receive an IP without issue. We are able to ping the laptop from a wired desktop machine and the laptop can ping back. However, when we attempt to use a remote desktop software (teamviewer to be specific) we are unable to connect. We use the machines IP address to make the connection, not the TV ID.
There is more than just Teamviewer that isn't working, this is just the application we are using to test connectivity with.
When I run the command #show datapath session table x.x.x.x I can see the Teamviewer request coming, but it is being blocked by the controller.
(Rowntree) #show datapath session table x.x.x.x Datapath Session Table Entries ------------------------------ Flags: F - fast age, S - src NAT, N - dest NAT D - deny, R - redirect, Y - no syn H - high prio, P - set prio, T - set ToS C - client, M - mirror, V - VOIP Q - Real-Time Quality analysis I - Deep inspect, U - Locally destined E - Media Deep Inspect, G - media signal Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Flags -------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- ----- x.x.x.x x.x.x.x 6 51200 5938 0/0 0 0 0 1/0 2 FDYC
We have tried playing around with the Statefull Firewall, and adjusting the Inital Roles, the AAA Profile, and the 802.1X Authentication... Nothing we change seems to make a difference. We have even tried the "authenticated" role everywhere but that doesn't seem to work either. We have checked under the Stateful Firewall settings to make sure Deny Inter User Traffic is not checked and it is not. We have also made sure it isn't set anywhere else.
The weird thing is, if we go to a machine in an entirely different subnet (a 172 subnet for instance), and attempt to connect via Tewmviewer, it works without a problem. It seems to only be between clients that are in the same subnet.
We are still very new to this software so I am pretty sure we have problem missed something pretty fundamental, but at this stage we are a little stumped.
Any suggestions on what we can try?
Solved! Go to Solution.
09-10-2012 01:08 PM
show acl hits
Also check the user table to make sure user is falling into the right role and that role has allowall ACL.
09-10-2012 01:48 PM
Thanks for your response.
It lead us down the path to a better understanding of what is going on.
Initially we did not have any users at all. With no captive portal or anything.
Looking at the #show user-table we could see that our client was stuck at the logon role.
So we enabled the captive portal for our test SSID and created a local user for testing purposes.
As soon as we did that we opened a browser on the test laptop and got the captive portal right away, we authenticated, and now we see that our role in the user-table has changed to authenticated. Which is the role we had assigned for the 802.11 authentication.
Now everything appears to be working correctly. We use use teamviewer, we can map drives, etc, etc..
It is a small step, but at least we can start to move forward with some additional testing.
I am sure we will have more questions later!
Thank you again!