Controllerless Networks

last person joined: 38 minutes ago 

Aruba Instant Wi-Fi: Meet the controllerless Wi-Fi solution that's easy to set-up, is loaded with security and smarts, and won't break your budget.
Expand all | Collapse all

AGAIN!!! IAP AppRF? When will things work?

Jump to Best Answer
  • 1.  AGAIN!!! IAP AppRF? When will things work?

    Posted Apr 08, 2015 10:13 AM

    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


    apprf.JPG



  • 2.  RE: AGAIN!!! IAP AppRF? When will things work?

    Posted Apr 08, 2015 02:30 PM

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



  • 3.  RE: AGAIN!!! IAP AppRF? When will things work?

    Posted Apr 08, 2015 02:41 PM

    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.



  • 4.  RE: AGAIN!!! IAP AppRF? When will things work?

    Posted Apr 08, 2015 03:02 PM

    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.  

     apprf.JPG



  • 5.  RE: AGAIN!!! IAP AppRF? When will things work?
    Best Answer

    Posted Apr 08, 2015 03:09 PM

    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

     

     

     



  • 6.  RE: AGAIN!!! IAP AppRF? When will things work?

    Posted Apr 08, 2015 03:23 PM

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

     

    apprf2.JPG



  • 7.  RE: AGAIN!!! IAP AppRF? When will things work?

    Posted Apr 08, 2015 03:23 PM

    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



  • 8.  RE: AGAIN!!! IAP AppRF? When will things work?

    Posted Apr 08, 2015 05:23 PM

    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.



  • 9.  RE: AGAIN!!! IAP AppRF? When will things work?

    Posted Apr 10, 2015 11:23 AM

    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...

     

    VC_settings.JPG

     

    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?



  • 10.  RE: AGAIN!!! IAP AppRF? When will things work?

    Posted Apr 10, 2015 11:42 AM

    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.