Wireless Access

In my guest wireless WLAN, I have a transparent proxy configured to redirect HTTP/HTTPS traffic to a proxy.  For the most part, it works well, but when I do a packet capture, there are some clients that are not getting redirected to the proxy but instead are being forwarded directly to the firewall.  This does not affect the users directly because the firewall allows the traffic, but the information security department is not happy that traffic is bypassing the proxy.

There is only one role configured in guest wireless after captive portal authenticaiton, which is appropriately named "Guest".  The firewall policies on the controller consist of the redirect for http/https and then an allow all policy.  I've included configuration snippets for the pertinent sections dealing the the guest role.

Does anyone have an idea why some users would not get redirected to the proxy in this configuration?

Also, the version of ArubaOS is 6.1.3.6

Thanks,

Robert

user-role guest
bw-contract 2MegUp upstream
bw-contract 15MegDown downstream
access-list session ProxyRedirectPolicy
access-list session Permit_All

ip access-list session ProxyRedirectPolicy
user any svc-http redirect esi-group ProxyGroup direction both
user any svc-https redirect esi-group ProxyGroup direction both
user host 172.x.x.9 tcp 15871 permit
!

ip access-list session Permit_All
any any any permit
!

esi ping ProxyCheck
frequency 15
timeout 5
retry-count 5
!
esi server Proxy-P1
trusted-ip-addr 172.x.x.10
untrusted-ip-addr 172.x.x.10
mode route
dport 8888
!
esi group ProxyGroup
ping ProxyCheck
server Proxy-P1
!

You need to type "show datapath session table <ip address of user>" to see if their traffic is hitting that rule, while your issue is happening.

Thanks for the response.  Here is a copy of the datapath session table, along with the output showing that the user has a L3 role of guest.  This users HTTP traffic was being sent directly to the firewall, bypassing the proxy.  I've attached a snippet of a packet capture that, in this case, shows a packet from the firewall directly to the user, and the source MAC address is the MAC address of the firewall.  And there are packets in the other direction that show the destination address to be the MAC of the firewall.

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
u - User Index

Source IP Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge UsrIdx UsrVer Flags
-------------- -------------- ---- ----- ----- ---- ---- --- --- ----------- ---- ------ ------ -----
172.XX.XX.230 8.8.8.8 17 63307 53 1/2 0 224 1 tunnel 181 10 50 ad3c FCI
172.XX.XX.230 8.8.8.8 17 52087 53 1/2 0 224 1 tunnel 181 d 50 ad3c FCI
172.XX.XX.230 184.73.152.242 6 50864 80 1/2 0 96 1 tunnel 181 6c 50 ad3c FC
172.XX.XX.230 17.149.32.33 6 50489 5223 1/2 0 96 54 tunnel 181 904 50 ad3c C
172.XX.XX.230 209.234.225.225 6 50911 80 1/2 0 96 1 tunnel 181 f 50 ad3c C
172.XX.XX.230 12.167.75.52 6 50715 443 1/2 0 96 31 tunnel 300 47b 50 ad3c C
23.21.207.212 172.XX.XX.230 6 80 50904 1/4 0 160 1 tunnel 181 27 0 0 F
184.73.152.242 172.XX.XX.230 6 80 50864 1/4 0 96 1 tunnel 181 6c 0 0 F
96.17.203.19 172.XX.XX.230 6 80 50910 1/4 0 160 0 tunnel 181 10 0 0
96.17.203.19 172.XX.XX.230 6 80 50905 1/4 0 160 0 tunnel 181 27 0 0 F
96.17.203.19 172.XX.XX.230 6 80 50903 1/4 0 160 0 tunnel 181 2c 0 0 F
96.17.203.19 172.XX.XX.230 6 80 50901 1/4 0 160 0 tunnel 181 2c 0 0 F
96.17.203.19 172.XX.XX.230 6 80 50898 1/4 0 160 1 tunnel 181 40 0 0 F
96.17.203.19 172.XX.XX.230 6 80 50913 1/4 0 160 0 tunnel 181 d 0 0
54.197.232.215 172.XX.XX.230 6 80 50724 1/4 0 160 0 tunnel 300 453 0 0

172.XX.XX.230 54.225.161.49 6 50909 80 1/2 0 160 0 tunnel 181 10 50 ad3c C
172.XX.XX.230 54.225.161.49 6 50897 80 1/2 0 160 0 tunnel 181 41 50 ad3c FC
172.XX.XX.230 54.225.161.49 6 50902 80 1/2 0 160 1 tunnel 181 2c 50 ad3c C
172.XX.XX.230 54.225.161.49 6 50900 80 1/2 0 160 0 tunnel 181 2c 50 ad3c FC
172.XX.XX.230 96.17.203.19 6 50913 80 1/2 0 160 0 tunnel 181 d 50 ad3c C
172.XX.XX.230 96.17.203.19 6 50898 80 1/2 0 160 1 tunnel 181 40 50 ad3c FC
172.XX.XX.230 96.17.203.19 6 50903 80 1/2 0 160 0 tunnel 181 2c 50 ad3c FC
172.XX.XX.230 96.17.203.19 6 50901 80 1/2 0 160 0 tunnel 181 2c 50 ad3c FC
172.XX.XX.230 96.17.203.19 6 50906 80 1/2 0 160 1 tunnel 181 21 50 ad3c C
172.XX.XX.230 96.17.203.19 6 50905 80 1/2 0 160 0 tunnel 181 27 50 ad3c FC
172.XX.XX.230 96.17.203.19 6 50910 80 1/2 0 160 0 tunnel 181 10 50 ad3c C
172.XX.XX.230 96.17.203.19 6 50908 80 1/2 0 160 1 tunnel 181 19 50 ad3c FC
54.235.139.23 172.XX.XX.230 6 80 50912 1/4 0 160 0 tunnel 181 d 0 0
209.234.225.225 172.XX.XX.230 6 80 50911 1/4 0 96 1 tunnel 181 f 0 0
54.225.161.49 172.XX.XX.230 6 80 50900 1/4 0 160 0 tunnel 181 2c 0 0 F

54.225.161.49 172.XX.XX.230 6 80 50902 1/4 0 160 1 tunnel 181 2c 0 0
54.225.161.49 172.XX.XX.230 6 80 50897 1/4 0 160 1 tunnel 181 41 0 0 F
54.225.161.49 172.XX.XX.230 6 80 50909 1/4 0 160 0 tunnel 181 10 0 0
172.XX.XX.230 54.235.139.23 6 50912 80 1/2 0 160 0 tunnel 181 d 50 ad3c C
172.XX.XX.230 207.223.6.23 6 50907 80 1/2 0 96 1 tunnel 181 20 50 ad3c FC
12.167.75.52 172.XX.XX.230 6 443 50715 1/4 0 96 30 tunnel 300 47b 0 0
172.XX.XX.230 23.21.207.212 6 50904 80 1/2 0 160 0 tunnel 181 27 50 ad3c FC
172.XX.XX.230 54.197.232.215 6 50724 80 1/2 0 160 0 tunnel 300 453 50 ad3c C
207.223.6.23 172.XX.XX.230 6 80 50907 1/4 0 96 1 tunnel 181 20 0 0 F
8.8.8.8 172.XX.XX.230 17 53 52087 1/4 0 224 1 tunnel 181 d 0 0 FI
8.8.8.8 172.XX.XX.230 17 53 63307 1/4 0 224 1 tunnel 181 10 0 0 FI
17.149.32.33 172.XX.XX.230 6 5223 50489 1/4 0 96 54 tunnel 181 904 0 0

Name: xxxxxxxxxxx, IP: 172.XX.XX.230, MAC: ac:cf:5c:53:39:61, Role:guest, ACL:3/0, Age: 01:19:15
Authentication: Yes, status: started, method: Web, protocol: PAP, server: Internal
Bandwidth contract = 2MegUp (2000000 bits/sec)
Bandwidth contract = 15MegDown (15000000 bits/sec)
Role Derivation: Matched server rule
VLAN Derivation: unknown
Idle timeouts: 0, ICMP requests sent: 0, replies received: 0, Valid ARP: 0
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=1, mba=0
Flags: innerip=0, outerip=0, guest=0, download=1, nodatapath=0, wispr=0
Auth fails: 0, phy_type: g-HT, reauth: 0, BW Contract: up:2 down:4, user-how: 14
Vlan default: 883, Assigned: 0, Current: 883 vlan-how: 0 DP assigned vlan:0
Mobility Messages: L2=0, Move=0, Inter=0, Intra=0, ProxyArp=0, Flags=0x0
Tunnel=0, SlotPort=0x1040, Port=0x1135 (tunnel 181)
Role assigment - L3 assigned role: n/a, VPN role: n/a, Dot1x cached role : n/a
Current Role name: guest, role-how: 2, L2-role: xxxxxxxxxxx-guest-logon, L3-role: guest
Essid: xxxxxxxxxxx, Bssid: 00:0b:86:73:03:a1 AP name/group: xxxxxxx/yyyyyyy Phy-type: g-HT
RadAcct sessionID:n/a
RadAcct Traffic In 491451/36874150 Out 787695/1125975286 (7:32699/0:0:562:42918,12:1263/0:0:17181:1270)
Timers: ping_reply 0, spoof reply 0, reauth 0
Profiles AAA:xxxxxxxxxxx-aaa_prof, dot1x:, mac: CP: def-role:'xxxxxxxxxxx-guest-logon' sip-role:'' via-auth-profile:''
ncfg flags udr 1, mac 0, dot1x 0, RADIUS interim accounting 0
IP Born: 1403112801 (Wed Jun 18 12:33:21 2014)
Core User Born: 1403112797 (Wed Jun 18 12:33:17 2014)
Upstream AP ID: 0, Downstream AP ID: 0
DHCP assigned IP address 172.XX.XX.230, from DHCP server 172.XX.XX.5
Device Type: Mozilla/5.0 (iPad; CPU OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Mobile/11B554a

Has there been a resolution to this issue? I'm experiencing a similar issue except that my users can no longer complete any http requests (can't get out to the Internet) without resetting their wifi connections.

The redirect will work for a little while, but once the user goes idle for about 15 minutes, once they try to access the Internet again, they can no longer get out without resetting their connection.

mbayhylle,

The user in this thread, his ESI redirect does not work, period.  Does yours work, but then after 15 minutes idle, does not work after that?  You might have a separate issue.  If that is the case, can you please open a separate thread, so that we can focus on your exact issue?

My redirect works, but fails work work after a certain amount of time. I've opened a new thread.

I did not say that my ESI did not work period.  I said:

For the most part, it works well, but when I do a packet capture, there are some clients that are not getting redirected to the proxy but instead are being forwarded directly to the firewall.  This does not affect the users directly because the firewall allows the traffic, but the information security department is not happy that traffic is bypassing the proxy.

I don't know if the 15 minute timeout is pertinant to my issue, but it would make sense.

But to answer mbayhylle's question, yes I am still having the problem.  I never received any further guidance after I made my last post.  I haven't spent a lot of time on it because I am going to upgrade my controllers soon, and I was hoping (fingers crossed) that it would be fixed in the latest release.

rluechtefeld,

Noted.  It is easier to resolve an issue if we can narrow down the circumstances.  If you observed circumstances similar to mbayhylle, then it could be the same issue.  If not, we should probably keep them separate, in case there are two separate issues.

Are all of your users on the same controller?

Your users with the problem, have they ever been able to connect that day, and then it stops like mbayhylle, or it just never works?

Have you opened a case so that TAC can take a look?

I haven't opened a case with TAC because I'm planning to do an upgrade to 6.4.2 as soon as I can remove some old AP-65s from the network.  I have the luxury of waiting because this issue is not visable to the end user in my case.

If the problem still exists after my upgrade, I'll open a TAC case.

rluechtefeld,

If you can, please update this thread, regardless of what happens.

Sorry it took awhile to do the preparation work for the code upgrade.  The cabling group had to locate all our AP65s so they could be replaced with AP205s.  

After the code upgrade to 6.4.2.1 (which went very smoothly), the issue of the ESI redirect not working has gone away.

I don't know why it was failing in the previous version, but it does appear to be resolved with the new code.