Wireless Access

last person joined: 13 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

External Firewall Hits Logging

This thread has been viewed 5 times
  • 1.  External Firewall Hits Logging

    Posted Feb 17, 2017 03:21 PM

    Is there a means by which the controll firewall logs can be forwarded to an external server?

     

    I have already setup the firewall logs under Security in the logging configuration at debugging level and sending to an external syslog received. I'm seeing the messages, but they are not very useful. Most if not all the messages are deny messages (even in debug mode) and I see a number of denied hits for a destination IP of the wireless client gateway versus the external IP they are attempting to hit.

     

    Bottom-line I'm trying to debug an issue where certain resources are not accessible from a captive role governed by the stateful firewall policy. I would like to be able to see in real-time a device being denied access as to identify resources that are incorrectly being denied.



  • 2.  RE: External Firewall Hits Logging

    EMPLOYEE
    Posted Feb 17, 2017 03:24 PM
    Type "show datapath session table <IP address of client>" on the command line of the controller to see what is being allowed and denied in real-time.


  • 3.  RE: External Firewall Hits Logging

    Posted Feb 17, 2017 03:32 PM

    Thank you Colin for the quick reply - I'm aware of that CLI command, but that requires determining the controller client is connected to, logging in and then replicating the issue. I was hoping to find a way to log that traffic outbound to an external server as to have both real-time and historical data.



  • 4.  RE: External Firewall Hits Logging

    EMPLOYEE
    Posted Feb 17, 2017 03:46 PM

    If you are using Airwave, it will automatically locate the controller that the user is on, and you can just use "run a command" for "show datapath session table" on the controller that the user is on;

     

    airwave.png



  • 5.  RE: External Firewall Hits Logging

    Posted Feb 17, 2017 03:55 PM

    That's an improvement - thank you. However there is no way to export this data via syslog? Even in debug mode the forwarded firewall logs show mostly UDP and ICMP traffic. The TCP traffic I do see (infrequent hits) appear to be denies destined for the network gateway address - not the actual source IP.



  • 6.  RE: External Firewall Hits Logging

    EMPLOYEE
    Posted Feb 17, 2017 03:58 PM

    You need to log on all ACLs in the user role to see everything.  It can drive the CPU up on the controller to do this, however, so it is not advised to log all sessions in a user role.

     

    What is your problem and what are you trying to do specifically?  There might be a better approach..



  • 7.  RE: External Firewall Hits Logging

    Posted Feb 17, 2017 04:09 PM

    I have a new out-of-the-box Samsung Android table I'm testing with and I cannot connect to Google Play. I have a number (20) of stateful firewall rules enabled to allow access to a myriad of places. If I remove the device from the captive state governed by those rules, it connects with no issue, so there is something in the firewall rules that is disallowing access to Google Play. I figured watching the firewall logs would point me in the right direction.



  • 8.  RE: External Firewall Hits Logging

    EMPLOYEE
    Posted Feb 17, 2017 04:28 PM


  • 9.  RE: External Firewall Hits Logging

    Posted Feb 20, 2017 09:09 AM

    Yes, I have setup a Google Play stateful firewall policy with those URLs as well as a number of others, still unable to access the store from a captive state.



  • 10.  RE: External Firewall Hits Logging

    EMPLOYEE
    Posted Feb 20, 2017 09:13 AM

    What is the output of "show rights <role>"?



  • 11.  RE: External Firewall Hits Logging

    Posted Feb 20, 2017 09:32 AM

    That was the key - thank you very much! The Google play firewall policy was applied to one of our captive roles but not another - once the policies were identical it appears to be working just fine now. Thank you!