Wireless Access

Hi Airheads experts,

 

Please help me to clear this topic. I need the exact firewall rules with directions between the APs and the controller. I search in Airheads, userguide and hardening guide as well but there are only a list of ports. I need in the following form. Forexample:

scr: AP dst: controller service: DHCP

scr: AP dst: controller service: PAPI

scr: AP dst: controller service: FTP, TFTP

scr: AP dst: controller service: GRE

scr: AP dst: controller service: udp 4500

or some policy is both direction etc.

 

Thank you in advance for your reply!

Zs

Where are you applying this ACL? On the controller itself or on your firewall ?

On the firewall.

In that case I suggest you post the question in your firewall vendor's forum to get exact command syntax to implement what you are trying to do.

This can also be implemented on the Aruba controller firewall if you need to, if you decide to use the controller firewall we can provide you the commands to allow those ports

Hi Victor,

I need the exact firewall rules in general schematic form. I am familiar with firewalls, thus I will be know the cli.

So who start the communication this is important in an stateful operation. In ClearPass or AirWave guides there are a gorgeous table (please see the attached file) and I need like that and I think this is very useful for others as well (the ports is documented but the directions don't). So If someone can give me the following form I will be grateful.

source: destination: service:

Ohh I see , I think I misunderstood your initial request

Here you go:
http://www.arubanetworks.com/techdocs/ArubaOS_60/UserGuide/Firewall_Port_Info.php

Thank you Victor!

If I see well the following ports and directions have to setup on the firewall, to the connection will be good. And it can be said that all of the following connections initiate from the AP itself.

Please correct it if it is wrong.

 

source: AP, destination: controller, service: DHCP

source: AP, destination: controller, service: PAPI

source: AP, destination: controller, service: FTP, TFTP

source: AP, destination: controller, service: GRE

source: AP, destination: controller, service: udp 4500

source: AP, destination: controller, service: NTP

source: AP, destination: controller, service: SYSLOG

 

If I turn on the CPSEC do I need to allow ntp and syslog traffic or those are going through the IPSEC tunnel as well as the others?

 

Thank you!

Zs

That's correct

Thank you for your help and work!

 

Br.,

Zs

Will this work if the a filter is applied on a switch port in which the AP connects?

 

So for example, if an AP is connected to a Juniper switch (EX4300) and I apply a filter to only allow the required ports/protocols for communication between AP and controllers (master and LMS) will that work?

 

Does the communication require a stateful connection? I will post the switch config momentarily.

 

Thanks,

hlavender

Now that I think about it...I guess it doesn't matter? TCP is connection oriented.

Why don't you try it on a single port and let us know?

Below if the firewall filter created on the Juniper switch. It is currently applied to just one switch port. When applied, the AP goes to a "down" status. Once removed, the AP comes back up. Not sure if anyone has tried this before and was successful? Added the multicast group as a last ditch effort.

 

firewall {
family ethernet-switching {
filter WAP-in {
term aruba-ap_udp {
from {
destination-port [ bootps dhcp tftp 8211 domain syslog 4500 ntp 53 ];
ip-protocol udp;
}
then accept;
}
term aruba-ap_udp_s {
from {
source-port 8211;
ip-protocol udp;
}
then accept;
}
term aruba-ap_tcp {
from {
destination-port ftp;
ip-protocol tcp;
}
then accept;
}
term aruba-ap_gre {
from {
ip-protocol gre;
}
then accept;
}
term permit-ping {
from {
icmp-type [ echo-reply unreachable ];
ip-protocol icmp;
}
then accept;
}
term permit-tcp_est {
from {
tcp-established;
ip-protocol tcp;
}
then accept;
}
term aruba-adp {
from {
ip-destination-address {
239.0.82.0/24;
}
ip-protocol udp;
}
then accept;
}
term default-deny {
then {
discard;
log;
count WAP-denied;
}
}
}

 

Thanks,

hlavender

Just curious, why are you doing an ACL for the AP? The access points are hardened and traffic is tunneled back to the controller. 

The customer has requested for the ports to be locked down since the AP's will be in an untrusted or common area. It's actually a little more to it than just that but that's the request in a nutshell.

Is the concern that someone would unplug the AP and connect another device? 

Yes. 

Basic 802.1X authentication solves that problem without the concern of using up all your ACE entries in the switch. 

If the AP were to be unplugged, the port would effectively reset and the next device that is plugged in would have to pass 802.1X or other authorization methods. 

Hhmmm, I didn't think about that. We have configured 802.1x currently on the wire so that may be an option.

 

Otherwise, any thoughts on acl's on switchports? This may still be the way they would like to go.

Issue resolved...for the most part.

 

The AP, which is an AP-325 was getting stuck while attempting to upgrade the software. During a wireshark packet capture, it was determined that passive FTP was being used. Since this uses "random" ports, the firewall filter on the Juniper EX4300 needed to be tweaked to allow this.

 

Made adjustments and now it works...the for most part bit was that additional ports are required for this to work. This would have been easier if this was passing through a firewall in flow mode or application layer firewall.

 

Anyhoo.

-hlavender