Wireless Access

Can i connect aruba ap via untrusted port? -

 

wired access port role = captive portal

It depends on your config, but by default it would not (unless it was a RAP).

 

Assuming your software level isn't too old, the controller considers IP connections from "untrusted" ports to be defined by the configuration within the "aaa authentication wired" global controller context. Within it, you can select a AAA profile, which determines an initial role of inbound traffic/devices/users etc. That initial role is how IP connections from a device on an untrusted port is handled (much like the way a AAA applies to a VAP).

 

I.e. if you setup an appropriate role within a AAA profile, and put it in the "aaa authentication wired" context, you should get the result you want.

 

Thanks!

And if he will change all the AP units from GRE to IPSEC? And allow them to connect with cert or user/pass to the controller?

They will be able to connect via the untrusted port?

 

 

That will work. Hence my comment "unless it was a RAP" (which will be IPSEC of course). And that assumes the default settings for the logon-control ACL haven't been altered of course!

i have applied the above mentioned configuration and this is working fine for non-Aruba Ap's. But unfortunately couple of Aruba's Ap are are terminating on same port with same VLAN and those Aruba's AP's are showing down may be because of the initial role assigned to them mentioned in AAA profile.
Is there any way to allow those 2 Ap's to connect via same port and get working i mean any acl or changing in intial user role?
offcource i understand RAP can work in that situation but for my learning i want to know if there is any other way to resolve this matter.

i think we can have some ACL in initial role which allow the IP addresses or MAC of those two AP's and assigned them default role.

what do you advice ?

I think I'd be inclined to do the following, which assumes those Aruba APs are doing DHCP...

 

Modify the role (that comes as a result of ingress into the controller untrusted port and aaa wired profile) to accomodate the following...

 

By rights, the AP will be using GRE. So you could just add an ACL to the role, which allows GRE from "users" (alias) to the controller IP (to which the AP is attaching). Assume your APs are able to discover the controller via DNS or maybe ADP?

 

If you've a PEF installed, you should fine an ACL called "ap-acl". If you add this to the role, that would work too. But (as it adds lots of open ports)...

 

What I can't tell without seeing the whole controller config, is whether this pokes any vulnerabilities in your security design overall!

 

 

I mean i should create following ACL

ip access-list session "AllowAP"
alias "user" alias "controller" "svc-gre" permit

and add it to the intial role of AAA profile right???

You should add UDP 8211, NTP, Syslog to that ACL.

 

Why do you want to put an access point on an untrusted port again?

 

That's a good start, but as has also been noted, you might well need to open some other ports for full operation.

 

Check the "ap-acl" that should be in your config (from a PEF). Use it as a template.

 

Again, I don't know if this has a negative consequence on your security. Why are you doing this?

 

From a security perspective, I'm actually thinking that if you have a good design reason to put APs on a network coming in on this untrusted port, they should be RAPs instead. Then all you'd need to do is open port UDP 4500. And, this would be on by default if you haven't changed the default PEF policies/acls. Why not convert them???

Unfortunately we have to provide services at some location immediately and we do not have any direct connectivity from the AP to trusted VLAN.
Certainly we would move these 2 AP's on trusted VLAN but now for we have to connect these AP's on untrusted VLAN on temporarily basis. That is why i am asking this thing for you..

ap-acl is also availabe i will also look into that is well

thank you for your supprt