Controllerless Networks

What will it take to get AppRF working? It seems that with every release, there's a little bit more but nothing useful? I'm not even looking for the Application reporting on my hardware but the Web reporting should be working just fine. Here's where I'm at...

Hardware - IAP-104/105's

InstantOS - 6.4.2.3-4.1.1.3_48994

AppRF - Enabled

I have the IAP's catching web data but not application data. I know application data isn't supported on my hardware. That's fine as I get that. The web data is where the issue is at as during collection....

1. It's reporting only a FRACTION of the actual web traffic going through it. - This is has been verified using Wireshark on the client, and checking the web applicaiton output against the IAP reporting.

2. There's no categorization at all. - What little that is being reported is always reported as "category-unknown"

I'm just wondering when these features are actually going to start to do something?

Pardon the tone, but this is becoming frustrating when you're always hearing "next release", "next release" and it's not there.

Rob

From my understanding IAP104/105 model is not supported for AppRF.

From pg. 257 of the Aruba Instant 6.4.2.0-4.1.1.x User Guide....

The application charts are not supported on IAP-104/105, IAP-134/135, IAP-175, and RAP-3WN/3WNP platforms. Only the web category charts are displayed for these IAP models.

I stated in my first post that application categorization isn't supprted on these models and I already get that. Web categorization supposedly is.

My bad.  You are correct.  I do see the Web Content only.  I'm running 6.4.2.3-4.1.2.1_49445 version on my IAP's.  

rgartley,

I would make sure that the IAP can reach the cloud by running the commandline on the IAP

show dpi webcategory-lookup http://www.bbc.com

I tested the above command on my IAP and it works fine.

Colin,

That's it!

USSDNAP44# show dpi webcategory-lookup http://www.bbc.com

Input URL: http://www.bbc.com
Request sent for CLOUD LOOKUP, please try again.

It's dying. Is this a paid service? What's killing this? It's not something as simple as DNS as that's configured.

Thanks again,

Rob

rgartley,

Try to ping aruba.brightcloud.com on the IAP to see if it can be reached.  If it cannot, make sure your IAPs are allowed to connect to the internet.

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?

rgartley,

For now, I can only answer with regards to the brightcloud issue;  Whatever VPN address your IAP gets from the pool on the controller needs to be routable outside of your network to the internet.  That means, when the traffic leaves the controller from that pool, your external firewall needs to know how to send it back to the controller.   It might work internally, but maybe not allowed on your firewall, or the firewall does not know how to return traffic to that pool back to the controller.  You might need a static route on your firewall pointing back to the controller that is terminating the IAP-VPN traffic.