Wireless Access

Hi All,

I need some help with setting up PBR on the controller. Please could someone detail me what to do for PBR.I would need very basic instructions on what to do on the controller and what needs to be done on the network/core switch side of things.

I have not seen any Aruba documentation that details the basic configuration. All I have at the moment is two controllers talking to each other, AP’s are up and broadcasting SSIDs, but not working.

The setup at the moment is that there are two controllers in a master local scenario. They would like all http and https traffic directed at their smoothwall appliance. I tried to create a basic user role, which had any source to destination smoothwall on http and https, but this did not work.

This is the current setup of the BYOD network and I have no choice but to try and setup PBR, but it is not working:

BYOD configuration at the moment

The client connects authenticates against the NPS and falls into the authenticated role.

The client then gets a captive portal from the smoothwall. There is no CP is assigned in the controller.

This has generic HTTP and HTTPs allowed in there at the moment and other basic services for the client to get online.

The client gateway is on the core switch, which then has a default route to the smoothwall IP address. This is working as it is now.

BYOD Setup – What they want

The client connects authenticates against the NPS and falls into the authenticated role.

The client then gets a captive portal from the smoothwall. There is no CP is assigned in the controller.

They would like only http and https traffic directed directly at the Smoothwall.

I have tried to send destination http and https traffic to Smoothwall, but that does not work and the client cannot get out until you have http and https generic rule in there.

Please advise on how to do this. 

http://community.arubanetworks.com/t5/forums/searchpage/tab/message?include_tkbs=true&location=category:Support-Documentation-Downloads&q=pbr

Thanks for the link. So What I learned from that is:

- Configure IP next hop list

-Create a policy with PBR option 

-Bind ACL to a user role 

Still not sure on the maste local setup for PBR. The controllers are at different sites, which use different IP ranges. Do I need an IP on the VLANS?, Should there be a shared address between the controllers? If so, I have been informed it is not good practice to have VRRP between master and local, do i have to make the controller interface IP the gateway for those networks? Any other config that I need to do to get this working?

You should configure it and make sure it works, first, and then layer on your use case.  If there is a different controller, you will probably need a different role for users on the second controller, because you would need to forward the traffic to a different gateway.

There is nothing in PBR that requires a VRRP.

I have set PBR up but the client experience is that it constantly disconnects and reconnects to the SSID. I was using mobile devices to test, which are apple and Android. Without PBR the client can connect to the SSID and not get disconnected. 

So to explain what has been done;

configured a next hop with priority one to be the smoothwall firewall. 

Added IP address to the VLAN on the controller and DHCP helper address.  

Editted DHCP scope so it points to the controller interface as its default gateway. 

Added a route on the smoothwall so it is aware of that network and can forward the traffic to the smoothwall interface IP address. 

Then tested a client and basically connects and disconnects immediately so I cannot confirm if it has an IP address. Is there anything else on the controller side that I need to fix or is this a network problem?

Please try and point me in the right direction. Unfortuently I do not have a network diagram to show what I am trying to do. 

Okay.  Here is what you need to do:

- The controller needs to have an ip address on the same l2 vlan of the nexthop that you want to send traffic to.  Why? The controller will do an ARP for that ip address to determine if the ip address in the next-hop-list is alive or not.  The ip address of the next hop must be in the route-cache of the controller to forward that traffic (show datapath route-cache) otherwise it will be black holed.  You need to configure that ip address into a name next hop list.

- You need to configure session acls for the user role to determine what traffic is permitted or blocked.  The simplest acl is "any any any permit".

- You need to configure a route ACL that determines what will be done for traffic that is permitted in a user role.  That route ACL would be used to determine WHERE traffic is sent after it is permitted by the session ACL.  That route ACL would then be assigned to the same user role.

- You can assign client ip addresses from a vlan that exists on the controller.  Traffic will still be policy-based-routed based on the route ACL.  You don't need to do a helper address for the device that you are trying to route through.

Typical user acl:

ip access list session userrules

any any any permit

Typical user role:

user-role userrole

ip access-list userrules <-------Add permit rules to the role

Typical next hop list:

ip nexthop-list gateway1

ip 192.168.1.5 (where 192.168.1.5 is the alternate router you want things routed through)

Create forwarding rule that will send only traffic to 216.31.192.23 to the next hop list (forward any other traffic normally):

ip access-list route "routingrules"
any host 216.31.192.23 any route next-hop-list "gateway1" position 1
any any any forward

Assign the forwarding rules to the user role using a routing policy map:

routing-policy-map role "userrole" access-list "routingrules"

 Expected behavior:

- All traffic should be permitted based on the userrules acl attached to the userrole role.

- Traffic to 216.31.192.23 will be routed to the nexthop list "gateway1", which has 192.168.1.5, which is an alternate router than the client's default gateway.

Short:

- Create a next hop list

- Create a session acl

- Create a route acl and reference your next hop list in the route acl for traffic that needs to be "routed" and "forward" for traffic that needs to use regular (your client's default gateway) routing.

- Apply the user session acl and the route acl to the user role using the "routing-policy-map" command

- Profit

Thanks Colin, 

This makes a lot of sense and breaks PBR up in stages. Unfortuently I did not have enough time onsite to fully implement this and had to work around it. I will make this a note for next time.