Colin,
This looks like the culprit as I'm unable to reach that site. So the question begs as to why? (I'm going to keep this in this thread as I'm hoping this will get a solved checkmark soon)
Some background...
All of our VC management, auth, anything from the AP's directly (not client traffic, except for Guest) traverses down a VPN tunnel back to physical 7200 controllers in our DC. These controllers are egress points for Guest traffic (as well as ingress for RAP's).
With that in mind, I try to connect to ping aruba.brightcloud.com, get zero response, and I check my data path. For this session aruba.brightcloud.com is resolving to 54.201.192.15 for reference.
(USLVNAPCTRL1) #show datapath session | include 54.201.192.15
54.201.192.15 10.20.178.29 6 80 50002 0/0 0 0 0 tunnel 22 0 1 40 F
54.201.192.15 10.20.178.29 6 80 50663 0/0 0 0 0 tunnel 22 0 1 40 F
54.201.192.15 10.20.178.29 6 80 64223 0/0 0 0 0 tunnel 22 0 1 40 F
10.20.178.29 54.201.192.15 6 50663 80 0/0 0 0 0 tunnel 22 0 1 60 YC
10.20.178.29 54.201.192.15 6 50002 80 0/0 0 0 0 tunnel 22 0 1 60 YC
10.20.178.29 54.201.192.15 6 64223 80 0/0 0 0 0 tunnel 22 0 1 60 YC
From this you can see that I'm getting the YC flags which I already know isn't good. What I also notice is that the VC is src-nat'ing everything on the way out. At this point I could go into my controller and see what policies are blocking this traffic, but then I started thinking.... why the heck is the AP src-nat'ing in the first place? The VC local LAN IP is fully routeable. Why isn't it using that IP address instead of the VPN IP address to the controller. Here's what I see in the VC config...
Although the VC has a static IP address assigned to it, there's no other information configured. I'm looking for some confirmation to some thoughts I have....
Since there's no mask, DFGW or anything, I'm assuming that the VC needs to use something so it's using it's VPN IP address as a fallback. I'm assuming this as when I check the datapath sessions on the VC itself, the source is the VC IP address, but the return destination is the src-nat of the VPN tunnel interface.
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
I - Deep inspect, U - Locally destined
s - media signal, m - media mon, a - rtp analysis
E - Media Deep Inspect, G - media signal
A - Application Firewall Inspect
RAP Flags: 0 - Q0, 1 - Q1, 2 - Q2, r - redirect to master
10.3.69.144 54.201.192.15 1 3 2048 0 0 0 1 local 4e FSRCI
10.3.69.144 54.201.192.15 1 0 2048 0 0 0 1 local 5d FSRCI
10.3.69.144 54.201.192.15 1 1 2048 0 0 0 1 local 58 FSRCI
10.3.69.144 54.201.192.15 1 4 2048 0 0 0 0 local 49 FSRCI
54.201.192.15 10.20.178.29 1 2 0 0 0 0 1 local 53 FNRYI
54.201.192.15 10.20.178.29 1 3 0 0 0 0 1 local 4e FNRYI
54.201.192.15 10.20.178.29 1 0 0 0 0 0 1 local 5d FNRYI
54.201.192.15 10.20.178.29 1 1 0 0 0 0 1 local 58 FNRYI
54.201.192.15 10.20.178.29 1 4 0 0 0 0 1 local 49 FNRYI
Quite honestly, it's always bugged me that the VC would send all auth traffic, mgmt traffic, everything else, over the VPN tunnel to the controllers. We're useing IAP VC so we don't have to depend on the physical controllers, but we do.
If I configure the VC IP settings in full, not just the IP Address and 32-bit mask, would all traffic come from that IP and not be source nat'ed from the VPN interface?
Are my thoughts behind this sound?