Wireless Access

I was trying to set up a separate Offsite Guest SSID that had it's own Internet connection, now that AOS 6.4.3 has support PBR (policy based routing).  That didn't work out so well for me, and I gave up 8 hours later.

 

Let me describe our current setup:

- Aruba 7030 running AOS 6.4.3.1 behind corporate router and NATing firewall

- Campus APs are both in controller's subnet and other corporate subnets

- default gateway for controller is the corporate router

- SSID & VLAN for corporate traffic, with a Windows server handing out the IPs

- SSID & VLAN for Internal Guest traffic, with the Aruba's internal DHCP server handing out the IPs

- both VLANs are trunked out of port 8 and

- corporate and Internal Guest traffic do not intermingle

 

We wanted to add another Offsite Guest SSID and VLAN with AP 275's that were set up as Remote APs that did not intermingle with the existing two VLANs, and a separate Internet connection with a public IP on port 7 of the controller.

 

I did the following:

• built the new WLAN (with SSID)
• built "Offsite Guest" VLAN
• configured the Aruba's internal DHCP server to hand out a new set of private IPs
• configured the "Offsite Guest" VLAN with the .1 of the new set of private IPs
• configured the "Offsite Guest" VLAN to do SNATing
• built "New Internet" VLAN with the new public IP
• Configured port 7 to use the "New Internet" VLAN
• created a PBR ACL matching on the new set of private IPs
• created a nexthop-list routing to the new public IP's default gateway
• applied that PBR ACL to the "Office Guest" VLAN 

But that did not work.  Clients could get an IP address, but could not ping outside the Offsite Guest VLAN, just the controller's Offsite Guest VLAN's IP.

 

What did I do wrong?  Or is this correct in theory, and should have worked?a

frnkblk,

 

Have you tried split-tunnel Captive Portal?  http://community.arubanetworks.com/t5/Controller-Based-WLANs/How-to-configure-Captive-Portal-for-Guest-Access-on-a-Remote-AP/ta-p/177144

 

 

 

 

Colin,

Thanks for the suggestion and link.  If I understand this approach correctly, each AP's traffic locally routed onto the Internet.  While that's not bad, my preference is that all the guest traffic be tunnelled back through the controller.

Frank

frnkblk,

 

I just re-read your first passage;  let's see if my suggestion below would work.

 

Does that ISP have its own router that assigns its own private ip addresses to internet users?  If so, this could be fairly straightforward.  You would need:

 

1 isolated VLAN on the controller

1 physical port on the controller assigned to that VLAN

The ISP router, with built in router that assigns ip addresses to guest clients and routes traffic (this is the key)

 

You would plug the private side of the ISP router into the separate VLAN on the isolated port on the controller.  Create a Virtual AP whose VLAN is the one assigned to the separate VLAN on that isolated physical port on the controller.  Plug the private side of the ISP router into the controller.  When users associate to the SSID, their traffic will be bridged to that separate physical port, get private ip address es from the ISP router and have traffic routed out to the internet.  The traffic would be completely separate from your existing WLAN traffic.

 

Would that work?

 

 

 

 

 

 

Colin,

What you described is what I ended up building (you described that approach in another Community post, thanks!).  But I'd like to elimininate that SOHO router and use the PBR and SNAT that's in the controller.  But if what I'm asking is "just not possible", then I will either need to be be satisfied with my current approach or submit a feature request.

Frank

frnkblk,

 

Quite frankly, I have never configured the new PBR feature, but we have used ESI (extended services interface) redirection to do policy based routing for some time now.  http://www.arubanetworks.com/techdocs/ArubaOS_64_Web_Help/Web_Help_Index.htm#ArubaFrameStyles/ESI/ESI_Configuration_Overvi.htm%3FTocPath%3DExternal%20Services%20Interface%7C_____3

 Here is what you would do:

 

esi ping health-30sec
  frequency 30
  timeout 1
  retry-count 2
!
esi server ISP-Gateway
  mode route
  trusted-ip-addr 192.168.1.254  (ISP private router address- must be routable to the controller, but not necessarily the guest users)
  untrusted-ip-addr 192.168.1.254  (ISP Router private address again - must be routable to the controller, but not necessarily the guest users)
!
esi group ISP-gateway-group
  ping health-30sec
  server ISP-Gateway

!
ip access-list new-guest-acl
 any any any redirect esi-group ISP-gateway-group direction forward
!
user-role new-guest
 session-acl new-guest-acl

Please let me know if you can try this.

 

 

 

Colin,

If I understand your ESI example it still requires an ISP router between the controller and the ISP Internet connection.  I would like to plug the ISP Internet connection directly into the controller and assign the controller the public IP address and have the controller do the NAT, DHCP, and appropriate routing for the Offisite Guest traffic, but send all the other traffic the existing way.

Frank

Frank,

 

 

I will get you some answers regarding your PBR setup.  Stay tuned.

 

 

Frank,

 

Two answers:

 

The "next hop" ip address should be the device upstream from the controller.  For example, if the controller has a public ip address, the next hop ip would be the router that is next upstream.  That ip address of course has to be routable to the controller.

 

As long as you are providing DHCP, you the controller will NAT traffic before doing the policy routing.

 

Also, use the "show datapath session verbose" command to see traffic being routed.  You should see the "r" and "R" flags indicating redirects and next hop routing.

 

 

 

 

 

Colin,

Thanks for the quick response.

For the next-hop IP address I did use the public IP's default gateway.

When you write, "As long as your are providing DHCP..." did that mean if the Aruba controller hands out IP addresses it will not work?

Is this something you'd like to lab up, or would you prefer to work through this on our production box, after this weekend?

Frank

Frank,

Can the controller ping the next hop? Did you run the "show datapath.." Command?

The engineer I spoke to told me the dhcp comment, but I assume he means that the devices need to simply get dhcp.

I think I have an idea of your setup, but could you post the snippet of your pbr config and user role, and a simplified diagram so we can replicate?

Colin,

Thanks for your guidance.  In less than 30 minutes this afternoon I built a working configuration.

 

One security snafu -- in order for this to work properly I have to have "ip routing" enabled on the two VLAN interfaces, but that means the clients can access any of the controller's IP interfaces, including the SSH and GUI interfaces.

 

How do I properly restrict the traffic -- do I need to put an ACL on the interior Wi-Fi client VLAN (pre-NAT) or the Internet-facing VLAN (post-NAT)?

Glad to hear it is working. Woild like to see your general config for the community if possible. Did you try to restrict traffic in the user role, first?

Colin,

 

Here's a sanitized configuration snippet:

 

 

ip dhcp pool vlan_10
 default-router 172.16.20.1
 dns-server <ip 1> <ip 2>
 domain-name acme.com
 lease 0 12 0 0
 network 172.16.20.0 255.255.252.0
 authoritative
!
ip dhcp excluded-address 172.16.20.1
!
ip nexthop-list Outdoor_WiFi_Nexthop
  ip <public default gateway> priority 5
!
ip access-list route PBR
  network 172.16.20.0 255.255.252.0 any any  route next-hop-list Outdoor_WiFi_Nexthop 
!
vlan 10 "Outside_Guest_WiFi_network" 
vlan 20 "Outside_Guest_WiFi_stub_link" 
!
interface vlan 20
	ip address <public IP> <public IP mask>
!
interface vlan 10
	ip address 172.16.20.1 255.255.252.0
	ip nat inside
	ip access-group "PBR" in

 

 

I see that I'm using guest role for this WLAN -- do I need to clone the guest role and modify that clone to block access to the controller IPs?

That would be the best way, yes.

Thank you for the config so others can see, along with the caveat.

Ok, I got ACLs in place now. Thanks again for the guidance.