Security

I have to replace an old wireless network with a new Aruba controller-based network. The existing network deploys multiple Guest VLANs, shared across two Internet bearers. That's fine in the existing setup: each VLAN is associated with only one internet connections, so IP addresses remain constant and such things as https and vpns work fine.

 

I need both bearers to carry the total traffic, and current best practice says to use only one Guest VLAN.

 

If I do that, the Guest VLAN must have access to the Internet via to two different bearers, with different subnet addresses (so I have enough bandwidth).

 

Now the problem: If the first packet from a wireless guest is routed through bearer "1", then the second is routed through on bearer "2", https and vpns will be broken because the addresses will change. (Oversimplification, I know, but I'm trying to keep it simple).

 

What I really need to do is arrange it so that when a device (identified by MAC address) associates with the network, any traffic from that device is always sent via the same bearer. That way, addresses stay constant and everything works.

 

Question is: can I do that in ArubaOS8.x and if so, how. If not, is there a recognised way around the issue.

 

Thanks for any advice

 

Jim

Do you currently have a device deciding what goes out what ISP?

No, the VLANs are trunked out of the controller, then directed to one or other of the bearers by native routing.

 

This works because I don't have multiple bearers available to each VLAN, but the other way round: several Guest VLANs using one Internet bearer each.

 

Jim

EDIT

What does the native routing?

If you create two VLANs, and put  both of those on the virtual AP profile (VLAN pool), the controller will load balance users from a single guest network into those two VLANs, which can be trunked to the load balancing infrastructure.

 

Does that make sense?

 

 

That makes sense, but I'd like to deploy a single VLAN (WLAN) which supports all Guest clients, but which can access the internet over two different routes (which is why its necessary to identify/force which Internet access each client should use by client MAC address, to maintain consistent routing/NAT-ing  of the client traffic). 

 

You said "which can be trunked to the load balancing infrastructure."...but I don't have a load-balancing infrastructure, I just take a bunch of guest VLANs and route them to one Internet bearer, and another bunch of VLANs and route them to the other Internet bearer (nothing clever here!)

 

Jim

So your controller is doing all the internet routing? No Firewall or router in between the controller and your ISPs?

I think a typical topology is that users will get put onto a guest vlan (or VLAN Pool as cjoesph suggested), then an upstream router or firewall would handle the best path selection from there.

I personally am a litle confused by your topology, would you be able to share a simple diagram of what it was, and what it is going to become?

I have confused issues by trying to simplify them! Sorry. The WLC is trunked to a core switch, and the traffic from each WLAN is sent across VLANs through the core switch to routers that connect to the Internet. At present no firewalls (another reason for the upgrade), just DNS-based filtering. 

That makes more sense.
Are your guest VLAN(s) publically routable, or are they private address that get NATed? If NAT, which device is doing the NAT?

We are running with RFC1918 addresses internally, and they are NAT-ed (NAT Overload) to a few public addresses by the routers at egress

Why don't you split the outbound traffic to two parts? So all destinations from 0.0.0.0 to 127.255.255.255 go via LINK 1 while all destinations 128.0.0.0 to 255.255.255.255 via LINK2.

 

In other words, instead of sending a client traffic from a particular link, you send traffic to a particular destination from a specific link..

 

Instead of equal cost default routes

0.0.0.0/0 via LINK1

0.0.0.0/0 via LINK2

 

Add static routes

 

0.0.0.0/1 via LINK1 cost 10

128.0.0.0/1 via LINK2 cost 10

 

As such, you are sure traffic will go from a particular link. It is not ideal but it can work. You can possibly add backup routes via the other link if the link fails.

 

0.0.0.0/1 via LINK2 cost 20

128.0.0.0/1 via LINK1 cost 20

 

Note: I don't think nexthop tracking is supported here so you better watch out.. This is just a workaround and you need to understand its limitations. If you really need to track the ISP links, you can check our SD-WAN solution..

Splitting the outbound traffic with static routes will work, but I was hoping that by some form of "round robin" MAC recognition driving the distribution, I could get the first client  (MAC Address) on the first bearer, second client (MAC address) on second bearer, third client on first bearer and so on, so that loading was "leveled out".

 

I can achieve something similar by not spliting the subnet into two parts, but into many parts , so for instance the first 62 clients (/26) go to bearer 1, then the next 62 go to beaer 2, then the next 62 go to bearer 1, etc. but on a large Guest subnet, that makes for a lot of static routes.

 

It's a suggestion that will work, and that I will use if there are no "smarts" in the controller to do it more elegantly....Aruba, please note, if this is not possible now, how about a future feature!

 

Thanks

 

Jim

presuming the WLC is the router for the clients, can you not just use ECMP to solve this ? If you have two default routes then any given 5 tuple flow will always hash to the same egress path thus preserving the public IP after the NAT.

The network topology will be WLC trunk-to-CoreSwitch (Cisco 9500)-to-multiple ISP routers-to-Internet. At this stage, I hadn't considered a L3 component between the WLC and the egress routers, and I'm unclear about what changes would be needed for ECMP to work...can you suggest details?

first can I ask if the two isp links are conncted to your c9500 core, and if that device is also the default gw for the guest clients, can it not be setup to do ecmp for the default route ?

 

yes you could bring the L3 connection back to the WLC but that also means you need to bring the 2 x ISP links back to the WLC too (which i admit is what i thought was the case originally, now i see they are connected to the c9500

 

 

The topology is functionally as you say. Even if it was not, this is a new network to replace the existing one, so I have freedom to do what is needed. Reason I was not considering L3 was primarily because I didn't want to rely on the ISPs CPE routers participating in L3, but it's looking like it may be the better option. Whatever, you have broken me out of the restrictions of thinking L2 only, so thanks for that.