Controllerless Networks

So there doesn't seem to be a VRD so I'm basing this off the user guide only. Basically having trouble with understanding the IAPs forwarding model, how this interacts with DHCP and VPN, and how this affects multiple SSIDs in different modes. Here's the setup..

The IAPs are in branch offices. The branches are connected back to Head Office via a private WAN. All internet access is through the HO. There are 7200 controllers in HO and IAP-135s in the branches. Controllers are connected to both Internal 10.x.x.x networks and DMZ 192.168.0.0 networks. Requirements are as follows:

Guest SSID

1. ALL guest traffic tunnelled to HO controller. This is so guest traffic does not transit the branch network unencrypted.
2. Controllers use default route to forward to DMZ side, which has a web proxy 
3. Clients will receive DMZ proxy configuration from DHCP
4. Clients have a policy denying access to Internal network
5. Clients can therefore only accces DMZ services or internet through the DMZ proxy

Corporate SSID

1. NO corporate traffic to be tunnelled,
2. Corp traffic will be layer 3 routed by the IAP into the branch network which will then route to HO if required
3. Controllers use specific route for 10.x.x.x to forward traffic to Internal side which has it's own web proxy
4. Clients are preconfigured with proxy configuration
5. Clients have a policy denying access to anything but the Internal network
6. Clients can therefore only accces Internal services or internet through the Internal proxy

 EDIT: No NAT requirement for either SSID

So to achieve this we configured the corporate SSID as a Local,L3 networks and found it to be working. According to the manual this mode does NOT use the VPN tunnel.

We then configured the VPN tunnel with a routing profile containing routes 0.0.0.0/0 as per guest requirement 1. The issue we found is that RADIUS traffic from the Corporate SSID is now tunnelled and the corp network no longer works. This is prior to configuring a guest SSID.

Even more strangely DHCP now fails on corporate traffic even theere is a scope on the IAP VC for this and it worked without the VPN. 

So it seems that the routing-profile is applied globally to all IAP traffic and that the description of Local,L3 mode incorrect. 

Generally I am wondering if IAP can even support the required setup. I have added +1 to the request for an Instant VRD by the way :)

Hi

Just a question, if the Branch offices are all connected via a private WAN would it not be better to turn the IAP's into campus AP's and have them all manged by the Controller. That way you could run the Corporate SSID in bridge mode and bridge all the traffic off to the local branch office LAN, then have all the guest traffic as a tunnel ssid back to the controller.

There would be additional licensing costs for the AP's but in terms of managing the system it would be a much simpler process.

That's actually a great idea. I don't see any issues with that.

The decision to go IAP was made before I came onto the project, so I'll have to look into whether there was a specific reason for it.

cheers!

Ok the reason for not using CAPs in bridge mode was that the wireless clients would then need to get an IP from the local branch subnet. 

A helpful Aruba rep has recommended using src-nat for the corp traffic to ensure it's not pushed through the tunnel. This makes sense but will mean natting corp traffic. Sounds like the best compromise however.

This is a great idea and one I would like to be able to do as well.  Generally the IAP VPN is for corporate traffic to be sent to the controller.

Would be great if there you could configure different routing on a per ssid basis.

---

@BGCIT wrote:

Ok the reason for not using CAPs in bridge mode was that the wireless clients would then need to get an IP from the local branch subnet. 

 

A helpful Aruba rep has recommended using src-nat for the corp traffic to ensure it's not pushed through the tunnel. This makes sense but will mean natting corp traffic. Sounds like the best compromise however.

---

BGCIT,

How do the wired clients at that branch function?  Do the wireless clients need different/additional functionality than those clients?

They have 4 or so different corporate roles for corporate users some of them BYOD so the customer just wanted to keep wired and wireless on separate IPs. That influenced the decision to go with instant. Of course it's not a strict requirement since he has a PEF license.

I've been thinking about some other potential issues with bridge mode.. For CAPs you would need to enable CPsec. This was discouraged last time I used it a couple of years ago, maybe the feature is improved now?

For CAPs or RAPs you still have user traffic encapsulated in GRE, which means the branch repeaters won't be able optimise traffic - their bandwidth is quite constrained. In early discussions they decided to compromise by only tunnelling guest traffic.

---

@BGCIT wrote:

They have 4 or so different corporate roles for corporate users some of them BYOD so the customer just wanted to keep wired and wireless on separate IPs. That influenced the decision to go with instant. Of course it's not a strict requirement since he has a PEF license.

 

I've been thinking about some other potential issues with bridge mode.. For CAPs you would need to enable CPsec. This was discouraged last time I used it a couple of years ago, maybe the feature is improved now?

 

For CAPs or RAPs you still have user traffic encapsulated in GRE, which means the branch repeaters won't be able optimise traffic - their bandwidth is quite constrained. In early discussions they decided to compromise by only tunnelling guest traffic.

---

Thank you for the additional information.

Does that BYOD traffic even need access to any assets at the remote site?  If not, you can just tunnel all the traffic to the headend, and you can enforce bandwidth shaping right there..

To bridge traffic, you can either go with CPSEC (global knob) or configure each AP as a RAP (fairly straihtforward).  To do bridging at remote sites, you have the most functional option which is IAP, on top of the other two.

When you speak of optimizing traffic, what do you mean specifically?  If you have BYOD users whose traffic is being tunneled back to the corporate headend with a CAP and you have a bandwidth contract for 1 meg, that user still will only be able to pass traffic at one meg, because his traffic will be buffered at the controller to meet that requirement.

---

Does that BYOD traffic even need access to any assets at the remote site?  If not, you can just tunnel all the traffic to the headend, and you can enforce bandwidth shaping right there.. 

Yes, that's a requirement. Local printing, file servers and so on.

---

 To bridge traffic, you can either go with CPSEC (global knob) or configure each AP as a RAP (fairly straihtforward).  To do bridging at remote sites, you have the most functional option which is IAP, on top of the other two.

---

So I think a RAP in persistent  & bridge mode would be about the same functionality, except for the clustering. Each branch has between 2 and 15 IAPs, so IAP definitely has an advantage over RAP there.

When you speak of optimizing traffic, what do you mean specifically?  If you have BYOD users whose traffic is being tunneled back to the corporate headend with a CAP and you have a bandwidth contract for 1 meg, that user still will only be able to pass traffic at one meg, because his traffic will be buffered at the controller to meet that requirement.

---

They are a XenApp shop and use Citrix Repeaters for WAN optimisation, so it's definitely preferred that corporate users are not tunnelled or they would lose most/all benefits. Unless the repeaters are clever enough to optmise xenapp traffic encapsulated in GRE :smileyhappy:

I came up with an alternative to src-nat

routing-profile
 route 0.0.0.0 7.255.255.255 10.1.11.11
 route 8.0.0.0 1.255.255.255 10.1.11.11
 route 11.0.0.0 0.255.255.255 10.1.11.11
 route 12.0.0.0 3.255.255.255 10.1.11.11
 route 16.0.0.0 15.255.255.255 10.1.11.11
 route 32.0.0.0 31.255.255.255 10.1.11.11
 route 64.0.0.0 63.255.255.255 10.1.11.11
 route 128.0.0.0 127.255.255.255 10.1.11.11

So this would route everything not 10.0.0.0/8 through the tunnel. Kind of an amusing workaround.

We tried this out and it does work - RADIUS traffic to 10.x.x.x is no longer tunnelled, but our DHCP went AWOL and corp client did not get an IP.

ip dhcp Corp
 server-type Centralized,L2
 server-vlan 52
 dhcp-relay
 dhcp-server 10.1.10.123

wlan ssid-profile Corp
 type employee
 essid Corp
 opmode wpa2-aes
 vlan 52

You would expect the request to be sent onto the branch network like RADIUS. But using 'show datapath session' commands on the VC we see RADIUS but oddly no sign of the DHCP..

Can anyone confirm what source IP address the VC will use when relaying? In this case I would hope it's the virtual controller address or ethernet address of that AP on the local branch network? Unfortunately I have limited access to the other network infrastructure to track this down.

Interesting solution.

Someone else maybe can answer the question about DHCP relay.

The source address for RADIUS, etc... when the IAP is doing a VPN is the INNER IP address as defined and handed out by the controller the IAP is terminating to.  The Inner IP address is defined in the L2TP pool under VPN settings on the controller.  

I would be interested in looking at your entire IAP config.  There is no reason why L3, Local wouldn't have worked.

Thanks

So, the DHCP seems to have just been bad a firewall rule. The routing profile wokaround seems to be a valid way of reversing your definition of what is corporate and only tunnelling non-corporate traffic.

Seth, we now see the RADIUS source as the normal ethernet address of the IAP since RADIUS traffic is no longer being tunnelled. When the RADIUS server is on a network that's part of the routing-profile it is indeed sourced from the VPN address.

cheers

Great...so it's working.  To make RADIUS appear from just the VC address, please enable "Dynamic RADIUS proxy" in system settings.