Wireless Access

Hi!

Scenario:

I have just installed a 7010 controller and should configure 2 SSIDs for backward availability during the integration phase of the CPPM Appliance.

Thought this could easily be done in minutes - only WPA2/AES PSK necessary - the 2 VLANs are already in a LACP trunk to the controller - DHCP Server is a Windows Server behind a L3 Router with a configured DHCP Relay which is in use already by the old HP MSM controller - only L2 trough the Aruba SSID "Tunnel".

Hours later - still not working....

I've read several posts now, that are very similar, but without a solution that works for me.

Problem description:

A wireless client can connect to the SSID, but does not receive an IP address.

A wired client on an access port on the 7010 controller works fine in booth VLANs.

What I have found already:

The first thing was, that I did not have a default user-role "authenticated" on my controller.

So I used the logon role during the wizard in the beginning.

Then I tried to add a manually generated user-role "authenticated" (not knowing if it is correct...)

!
user-role authenticated
 access-list session global-sacl
 access-list session apprf-authenticated-sacl
!

Result: No difference.

The client still can connect to the SSID, but does not receive an IP address.

In the dashboard I can see the client with the role "authenticated" (Forward mode: Tunnel) but without IP address.

The AAA profile vor the Virtual AP:

!
aaa profile "tiw-private-aaa_prof"
   initial-role "authenticated"
   mac-default-role "authenticated"
   authentication-dot1x "dot1x_prof-cqi86"
   dot1x-default-role "authenticated"
!

WLAN SSID

!
wlan ssid-profile "tiw-private-ssid_prof"
   essid "tiw-private"
   opmode wpa2-psk-aes
   hide-ssid
   wpa-passphrase 52376642e73ce23bdb1c4260d1b70cbebed7687d005ec7ac
   ht-ssid-profile "tiw-private-htssid_prof"
!

PEFNG Licenses are installed and available (flag: E in the GUI)

I'm using ArubaOS 6.4.3.6 (build 52927)

Any ideas or a running configuration file meeting the same requirements would be really helpful.

Many thanks in advance!

Manfred

Innsbruck/Austria

The role "authenticated" needs an "allowall" acl at the bottom of it.  Those two ACLs are system acls and doni't really allow anything.

Hi!

Thank you that you had a look at my problem.

I tried what you've suggested from the Web-GUI - Result:

!
user-role authenticated
 access-list session global-sacl
 access-list session apprf-authenticated-sacl
 access-list session allowall
!

but still the same.

(Or do I have to activate/restart something for this new settings to start working?)

When I look at the above 3 policies I can't see any rules in it - or are they invisible in the Web-GUI?

Manfred

On the commandline, type "show rights authenticated" to see what ACLs are in that role..

Hi!

I have looked at it, but don't see any ACLs in these Policies

(attiwwctrl01) #show rights authenticated

Valid = 'Yes'
CleanedUp = 'No'
Derived Role = 'authenticated'
 Up BW:No Limit   Down BW:No Limit
 L2TP Pool = default-l2tp-pool
 PPTP Pool = default-pptp-pool
 Number of users referencing it = 2
 Periodic reauthentication: Disabled
 DPI Classification: Enabled
 Youtube education: Disabled
 Web Content Classification: Enabled
 ACL Number = 55/0
 Max Sessions = 65535

 Check CP Profile for Accounting = TRUE

Application Exception List
--------------------------
Name  Type
----  ----

Application BW-Contract List
----------------------------
Name  Type  BW Contract  Id  Direction
----  ----  -----------  --  ---------

access-list List
----------------
Position  Name                      Type     Location
--------  ----                      ----     --------
1         global-sacl               session
2         apprf-authenticated-sacl  session
3         allowall                  session

global-sacl
-----------
Priority  Source  Destination  Service  Application  Action  TimeRange  Log  Expired  Queue  TOS  8021P  Blacklist  Mirror  DisScan  ClassifyMedia  IPv4/6  Contract
--------  ------  -----------  -------  -----------  ------  ---------  ---  -------  -----  ---  -----  ---------  ------  -------  -------------  ------  --------
apprf-authenticated-sacl
------------------------
Priority  Source  Destination  Service  Application  Action  TimeRange  Log  Expired  Queue  TOS  8021P  Blacklist  Mirror  DisScan  ClassifyMedia  IPv4/6  Contract
--------  ------  -----------  -------  -----------  ------  ---------  ---  -------  -----  ---  -----  ---------  ------  -------  -------------  ------  --------
allowall
--------
Priority  Source  Destination  Service  Application  Action  TimeRange  Log  Expired  Queue  TOS  8021P  Blacklist  Mirror  DisScan  ClassifyMedia  IPv4/6  Contract
--------  ------  -----------  -------  -----------  ------  ---------  ---  -------  -----  ---  -----  ---------  ------  -------  -------------  ------  --------

Expired Policies (due to time constraints) = 0

If configured now a static ip address on the client.

When I look at the clients status in the Web-GUI I can see that there is a "deny" for my ICMP ping from the client to the default gateway - and: the client has the role "authenticated" but isn't authenticated (is that the problem?)

I had a quick look in my Labguide from the Mobility Boot Camp from last year - there is a very similar scenario in Lab3 - as I remember this worked without any problems.

I have changed the initial role to "logon" which also has no ACLs in it - same problem

See the denys:

(attiwwctrl01) (config) #show datapath session table 10.3.0.10


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
       r - Route Nexthop
       A - Application Firewall Inspect


Source IP       Destination IP  Prot SPort DPort  Cntr    Prio ToS Age Destination TAge Packets    Bytes      Flags
--------------- --------------- ---- ----- ----- -------- ---- --- --- ----------- ---- ---------  --------- ---------------
10.3.0.10       10.3.0.12       1    1395  2048   0/0     0    0   0   tunnel 10   2    0          0          FDYC
10.3.0.10       239.255.255.250 17   62197 1900   0/0     0    0   0   tunnel 10   3    0          0          FDYC

(attiwwctrl01) (config) #

(attiwwctrl01) (config) #show user-table ip 10.3.0.10
Name: , IP: 10.3.0.10, MAC: 5c:51:4f:8a:36:5d, Age: 00:00:03
Role: logon (how: ROLE_DERIVATION_INITIAL_ROLE), ACL: 2/0
Authentication: No, status: not started, method: , protocol: , server:
Role Derivation: ROLE_DERIVATION_INITIAL_ROLE
VLAN Derivation: Default VLAN
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 27
phy_type: a-VHT-80, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 1
Vlan default: 3, Assigned: 3, Current: 3 vlan-how: 1 DP assigned vlan:0
Mobility Messages: L2=0, Move=0, Inter=0, Intra=0, Flags=0x0
SlotPort=0x2100, Port=0x1000a (tunnel 10)
Essid: tiw-private, Bssid: 04:bd:88:79:e6:30 AP name/group: AP_xxx_West_Raum1/xxxxxxxx Phy-type: a-VHT-80
RadAcct sessionID:n/a
RadAcct Traffic In 107/14708 Out 0/0 (0:107/0:0:0:14708,0:0/0:0:0:0)
Timers: L3 reauth 0, mac reauth 0 (Reason: ), dot1x reauth 0 (Reason: )
Profiles AAA:tiw-private-aaa_prof, dot1x:dot1x_prof-cqi86, mac: CP:n/a def-role:'logon' sip-role:'' via-auth-profile:''
ncfg flags udr 0, mac 0, dot1x 1, RADIUS interim accounting 0
IP Born: 1457516265 (Wed Mar  9 10:37:45 2016)
Core User Born: 1457510752 (Wed Mar  9 09:05:52 2016)
Upstream AP ID: 0, Downstream AP ID: 0
User Agent String:
Max IPv4 users: 2
L3-Auth Session Timeout from Radius: 0
Mac-Auth Session Timeout Value from Radius: 0
Dot1x Session Timeout Value from Radius: 0
CoA Session Timeout Value from Radius: 0
Dot1x Session Term-Action Value from Radius: Default
Reauth-interval from role: 0
Number of reauthentication attempts: mac reauth 0, dot1x reauth 0
mac auth server: N/A, dot1x auth server: N/A
Address is from DHCP: no
Per-user-log pointer 0x13002bc (id 35), num logs 56

(attiwwctrl01) (config) #

I don't need any acls or the firewall for this scenario as there is a company firewall in place.

Maybe I will have to go back to the Aruba school...

Manfred

Once the Policy Enforcement License is in place, you at least need an ACL that allows all traffic to allow that client to pass traffic.  Do this:

config t

ip access-list session allowall
any any any permit
ipv6 any any any permit
exit

That will create an "any any any" under your allowall ACL.

Make the authenticated role the initial role.

THAT makes sense - and now I understand the problem!

But this did not work with my "authenticated" initial role, as there are 2 other policies (global-sacl/,apprf-authenticated-sacl/) before the "allowall" policy which have no rules in it - so "deny" is the result.

To proof this I used the "logon" rule - added the "allowall" policy and configured it as the inital role - SOLVED...

I did not remember, that there is (as almost...) an implicit "deny all" rule also at the end of a firewall policy without rules - my fault...

Thank you for your patience with a newbie - you helped me to help myself - that rises my expierence in the best of all ways - still many things to learn...

Now Looking forward the CPPM integration...

Manfred

It should work with the authenticated role.  Both of those policies are system policies and if there is a policy with an any any any permit, it should work.

It is quite possible that the ACL was denying existing connections and you would have to reconnect the client to have a new session where the any any any permit was applied.

I agree - DHCP/ICMP works with these system policies.

Maybe because I have added the default security policies (which where missing) as you described in the Post: Security Policies not having rule statements

(This is also an important fact for the solution I think as it is not possible to add a new User Role without these default system policies; they can't be deleted and it's not possible to insert a rule before these 2 "system rules".)

Conclusion:

The "authenticated" User Role is not really an "allowall" User Role!

I have found - for example-  a "Deny" to the internal DNS Server Adress for the destination port TCP 445 MS SMB Direct Port). The client is not fully functional inculding these system policies.

- Are these system policies documented?

- How can I configure a new User Role without these policies

  (I don't want to insert rules in these policies)

Manfred

It seems that you might have added the PEF license and typed "write mem" or "save configuration" before rebooting.  If you do that, it ends up NOT creating all of your default roles or ACLs correctly.  Attached is a text file that you can copy and paste into the commandline of your controller (use SSH, instead of the console) so that all your default roles and ACLs can be restored.

Attachment(s)

firewallpolicies.txt   11 KB 1 version

I found this out already - must have been so - can't remember exactly, but theres a silly question when you initiate the reboot in the Web-GUI: "Do you want to save the configuration?"

There should be a note in the installation manual...

I've done this already with the Textfile you posted in the post http://community.arubanetworks.com/t5/Wireless-Access/Security-Policies-not-having-rule-statements/m-p/250087#M54372 I mentioned earlier.

Is this an updated version?

Manfred

There probably should be a note in the user manual that when you install the PEF license that you should not save the configuration before rebooting.  I will pass that on.

The version I just posted is the same as the one before.  If you pasted it in, this is what your authenticated role should have looked like:

user-role authenticated
 access-list session global-sacl
 access-list session apprf-authenticated-sacl
 access-list session ra-guard
 access-list session allowall
 access-list session v6-allowall

Since it didn't look like that, I am assuming that something went wrong.

It now looks exactly like that.

Tomorrow I will be at the customer site and test it with the initial role "logon" which I think will work now.

Manfred

The initial role "Logon" is supposed to be for Captive Portal connections only.  If that is what you want to do, you are on the right track.  If not, you should use "authenticated" for the initial role.

Hi!

Now I'm using the user-role "authenticated" as the inital role and it works as planned.

Manfred