Wireless Access

We have acquired pefng licenses for our controller with arubaos 6.5.3.1 and installed it today. Everything was working fine before the installation of the licenses. After the installation, configuration was extended with standard roles etc. and everything looks the way it should be.

We use dot1x with radius authentication for the wireless connection. Clients can still authenticate successfully and are assigned the dot1x-default-role as set in the aaa profile. However, the only traffic passing through after authentication is the traffic allowed for user-role logon (ping, dns).

After much searching and testing I have added logging to the allowall access-list and added an additional access-list with logging to the logon role. To my big surprise I now can see that all client traffic is first permitted by the allowall and then denied by the logon role which is consistend with what I see on the client.

Here an extract of the configuration with a test aaa profile.

user-role logon
 access-list session logon-control
 access-list session captiveportal
 access-list session vpnlogon
 access-list session v6-logon-control
 access-list session denyalllog
!
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
!
ip access-list session denyalllog
  any any any deny log 
!
ip access-list session allowall
  any any any permit log 
  ipv6 any any any permit 
!
aaa profile "Test-aaa_prof"
   authentication-dot1x "dot1x_prof-sps67"
   dot1x-default-role "authenticated"
   dot1x-server-group "Test_srvgrp-bjd43"
!

Now the logs show this:

Aug 15 20:29:23 2017 neon1 authmgr[4117]: <124006> <4117> <WARN> <neon1 10.25.1.101>  {94} TCP srcip=<client-ip> srcport=55645 dstip=17.253.55.206 dstport=80, action=permit, role=authenticated, policy=allowall
Aug 15 20:29:23 2017 neon1 authmgr[4117]: <124006> <4117> <WARN> <neon1 10.25.1.101>  {95} TCP srcip=<client-ip> srcport=55645 dstip=17.253.55.206 dstport=80, action=deny, role=logon, policy=denyalllog

show user shows the client in authenticated role. The client can ping any ip address possible, even using dns host names, but nothing else.

I haven't found any documentation explaining what could be going on. Actually, everything I have read makes me think that a client can only have a single role at any given time, so those logs don't make any sense to me.

What am I missing here? Why is the logon role firewall policy applied to all traffic even for users in a different role?

I would disable the logging and use "show datapath session table <ip address of client>" instead.

You honestly should not edit the logon (system) role.

---

@cjoseph wrote:

I would disable the logging and use "show datapath session table <ip address of client>" instead.

I did that, too, but output quickly changes thus makes it hard to track. Now I have tried to reduce client traffic to a minimum and it seems there is actually one syn packet getting a response which is dropped.

Logs:

Aug 15 21:27:26 2017 neon1 authmgr[4117]: <124006> <4117> <WARN> <neon1 10.25.1.101>  {156} TCP srcip=<client-ip> srcport=56967 dstip=216.58.213.196 dstport=80, action=permit, role=authenticated, policy=allowall
Aug 15 21:27:26 2017 neon1 authmgr[4117]: <124006> <4117> <WARN> <neon1 10.25.1.101>  {157} TCP srcip=216.58.213.196 srcport=80 dstip=<client-ip> dstport=56967, action=deny, role=logon, policy=denyalllog
Aug 15 21:27:27 2017 neon1 authmgr[4117]: <124006> <4117> <WARN> <neon1 10.25.1.101>  {158} TCP srcip=<client-ip> srcport=56967 dstip=216.58.213.196 dstport=80, action=permit, role=authenticated, policy=allowall
Aug 15 21:27:27 2017 neon1 authmgr[4117]: <124006> <4117> <WARN> <neon1 10.25.1.101>  {159} TCP srcip=<client-ip> srcport=56967 dstip=216.58.213.196 dstport=80, action=deny, role=logon, policy=denyalllog

show datapath session table <client-ip>:

Source IP       Destination IP  Prot SPort DPort  Cntr    Prio ToS Age Destination TAge Packets    Bytes      Flags           
--------------- --------------- ---- ----- ----- -------- ---- --- --- ----------- ---- ---------  --------- --------------- 
216.58.213.196  <client-ip>   6    80    56967  0/0     0    0   0   pc0         4    1          60         FDC             
<client-ip>   216.58.213.196  6    56967 80     0/0     0    0   0   tunnel 101  3    2          128        FDYC            

Both are flagged with D. odd. And it also doesn't show this for every connection attempt but only for some. For most connection attempts the first line for the response never appears and the remote server doesn't get anything, i.e. all outgoing traffic from the client is already dropped...

 

You honestly should not edit the logon (system) role.

---

Well, I saw the increasing hit count in the firewall hits monitoring page of the controller and wanted to know what it is exactly. Adding a policy seemed to be the only way to find out what it is exactly (even though hit counts suggested that the logon role deny and the authenticated permit increased together). And it wasn't meant to be permantent either.

You should make your port channel interface trusted.  By default it is untrusted.  Making it untrusted would assign the logon role to it.

---

@cjoseph wrote:

You should make your port channel interface trusted.  By default it is untrusted.  Making it untrusted would assign the logon role to it.

---

Just found that, too. That's it. Now it's working. Thanks!