Wireless Access

Is there a guide which explains how to setup version 8 with mulitple sets of controllers in different locations Hub and spoke for guest internet to a single DMZ. Since user's are balanced between both controllers in the cluster user traffic would only work from one controller if using the VRRP IP as the source of the GRE tunnels. 

The user guide should be sufficient to configure what you are asking.

You could go through the Airheads Clustering Videos on Youtube as a reference.

 

As for the Guest Traffic in the DMZ, You could setup Multizone where the DMZ would be a DataZone.

 

Could you break down your exact requirement and include a  basic topology diagram if possible?

 

--Give Kudos: found something helpful, important, or cool? Click Kudos Star in a post.
--Problem Solved? Click "Accepted Solution" in a post.

 

 

The requirements are a GRE tunnel from a cluster pair of controllers to a single controller in a different routed network. My question is do I need now to create two GRE tunnels from each controller in the cluster instead of one which I'm doing now in Version 6 with the VRRP Ip address.

 

 If that's the case how does the single controller know where to send traffic back to if a user is moved from one controller to another in the cluster. 

 

I know I can multizone the guest SSID but the controllers which are in the DMZ are not big enough to handle that many Access points. 

 

I will check the cluster videos but I don't remember anything said about GRE tunneling between controllers.  Another option is to just share the guest vlan between controller over our switch. Were going to test this in a lab next week.

 

I was just wondering if anyone has tried it. Seems like most don't use GRE tunneling for un-trusted traffic like a guest internet just connecting a vlan to the controller from the internet firewalls which makes sense if your internet firewalls are colocated with the controllers but we have some that are not. 

On how to configure GRE tunneling (L2 or L3) between two devices,

 

This may be of help,

 

https://www.arubanetworks.com/techdocs/ArubaOS_85_Web_Help/Content/arubaos-solutions/1cli-commands/tunnel-group.htm?Highlight=tunnel%20group

 

You could point the traffic to the A-UAC as this remains the same when a client roams(unless the device goes down then your S-UAC becomes the A-UAC)

 

 

--Give Kudos: found something helpful, important, or cool? Click Kudos Star in a post.
--Problem Solved? Click "Accepted Solution" in a post.

---

@kell490 wrote:

Is there a guide which explains how to setup version 8 with mulitple sets of controllers in different locations Hub and spoke for guest internet to a single DMZ. Since user's are balanced between both controllers in the cluster user traffic would only work from one controller if using the VRRP IP as the source of the GRE tunnels. 

---

In a word, there is not guide to setting it up.

 

It can get complicated depending on your design. Are you authenticating guest users at the MD or are you just sending them to the DMZ and the DMZ is an untrusted interface doing the authentication?  In most cases you would need a GRE tunnel from each MD to the DMZ controller, and the source ip address in the tunnel command on the MD side would be the reachable management ip address between each MD and the DMZ controller.  Having the source ip address of the tunnel as the VRRP in a cluster will not help,  because the MD that has control of the VRRP cannot deliver traffic to every client as you have discovered.  You would also want to exclude the tunneled VLAN from the cluster, otherwise the cluster would come up layer 3, which you also do not want.  You also would not want to have inter-tunnel-flooding enabled on the DMZ side so as not to introduce a loop.  Those are the big general pieces, but admittedly they might not fit all scenarios.

 

 

We are doing guest authentication at on the MD using clearpass.

Currently our guest network comes from 3 sets of Version 6.x local controllers using VRRP for redundancy which 2 are in different data centers. Each set has a GRE tunnel with source IP of the VRRP IP address.
We haven't upgraded yet this was something I have been testing in the lab.

Some things which I need to configure
1. DMZ controller needs to have inter-tunnel-flooding turned off which is on by default. What about the MD side leave that on?

2. Each MD in the cluster will need its own GRE tunnel. I'm assuming the source will be the controller IP?

3. Exclude the guest vlan sharing from the cluster

I recommend someone at Aruba should add this to the guide.

Thanks for your help

 

 

 

 

---

@kell490 wrote:

We are doing guest authentication at on the MD using clearpass.

Currently our guest network comes from 3 sets of Version 6.x local controllers using VRRP for redundancy which 2 are in different data centers. Each set has a GRE tunnel with source IP of the VRRP IP address.
We haven't upgraded yet this was something I have been testing in the lab.

I think your deployment is complicated enough that you should ask your Aruba SE for advice on this, along with this thread.  Your deployment involves specific design assistance.

 

Some things which I need to configure
1. DMZ controller needs to have inter-tunnel-flooding turned off which is on by default. What about the MD side leave that on?  

It depends.  The goal of turning off inter-tunnel-flooding is to prevent a loop.

2. Each MD in the cluster will need its own GRE tunnel. I'm assuming the source will be the controller IP?

 In a clustered environment, yes.

3. Exclude the guest vlan sharing from the cluster

This is because it is possible that controllers in a cluster would not be able to see each other through the tunnels on that VLAN and you don’t want the cluster to end up in L3 as a result.

I recommend someone at Aruba should add this to the guide.

Thanks for your help

 

 

 

 

---

In ArubaOS 8, we currently have two deployments in the field, I am aware of, of the Guest L2 GRE tunneling from multiple clusters to the DMZ.

1. L2 GRE tunnel from each node in the cluster to the same DMZ controller.

2. One L2 GRE tunnel from the VIP of a VRRP instance that includes all the cluster nodes to the DMZ controller.

 

If option 2 is selected, we should be aware that the guest VLAN traffic between cluster nodes will need to go through the Uplink switch. Another requirement is versions 8.3.0.7 or higher, 8.4.0.3 or higher, 8.5 and higher.

 

We thought of option 2 we rather not have guest internet traffic inside our core network. We are looking at using a tunnel for each MD in the cluster. The DMZ side we will turn on tunnel-loop-prevention. 

Option 2 is the only way to go have the guest vlan accross the uplink switch because if one excludes the guest vlan from the cluster users on the guest WLAN which is 70% of our wireless lan take as long as 20 seconds to fail over to the 2nd controller during reboots such as upgrades. It defeats the propose of having version 8 layer 2 cluster. What we have done in our test lab is setup the same as our Version 6 enviroment one tunnel from each cluster node using VRRP VIP address as the source. The master controller of the VRRP instance tunnel is UP/UP the back up controller is up/down. While I'm able to ping from the backup vrrp controller though the tunnel not exactly sure if I will be able to use firewall statement to redirct to the tunnel # when users are on the backup VRRP cluster node because were going to a cluster active / active controller enviroment. I will have to test this in the lab. 

 

My understanding that the firewall redirect to the tunnel # keeps users from being able to see other users on the guest wifi stops port scanners. We also enable the WLAN switch Deny inter user traffic. My hope is if we have to give up the redirect to the tunnel this switch will keep users from being able to connect to one another. 

Which 8.x version you will be setting up L2 GRE tunnel between local controller cluster VIP and DMZ VRRP IP. 

I too have similar scenario of upgrading 6.x to 8.x.

I'm planning to set this up in lab 

---

@kell490 wrote:

Option 2 is the only way to go have the guest vlan accross the uplink switch because if one excludes the guest vlan from the cluster users on the guest WLAN which is 70% of our wireless lan take as long as 20 seconds to fail over to the 2nd controller during reboots such as upgrades. It defeats the propose of having version 8 layer 2 cluster. What we have done in our test lab is setup the same as our Version 6 enviroment one tunnel from each cluster node using VRRP VIP address as the source. The master controller of the VRRP instance tunnel is UP/UP the back up controller is up/down. While I'm able to ping from the backup vrrp controller though the tunnel not exactly sure if I will be able to use firewall statement to redirct to the tunnel # when users are on the backup VRRP cluster node because were going to a cluster active / active controller enviroment. I will have to test this in the lab. 

 

My understanding that the firewall redirect to the tunnel # keeps users from being able to see other users on the guest wifi stops port scanners. We also enable the WLAN switch Deny inter user traffic. My hope is if we have to give up the redirect to the tunnel this switch will keep users from being able to connect to one another. 

---

---

@kell490 wrote:

Option 2 is the only way to go have the guest vlan accross the uplink switch because if one excludes the guest vlan from the cluster users on the guest WLAN which is 70% of our wireless lan take as long as 20 seconds to fail over to the 2nd controller during reboots such as upgrades. It defeats the propose of having version 8 layer 2 cluster. What we have done in our test lab is setup the same as our Version 6 enviroment one tunnel from each cluster node using VRRP VIP address as the source. The master controller of the VRRP instance tunnel is UP/UP the back up controller is up/down. While I'm able to ping from the backup vrrp controller though the tunnel not exactly sure if I will be able to use firewall statement to redirct to the tunnel # when users are on the backup VRRP cluster node because were going to a cluster active / active controller enviroment. I will have to test this in the lab. 

 

My understanding that the firewall redirect to the tunnel # keeps users from being able to see other users on the guest wifi stops port scanners. We also enable the WLAN switch Deny inter user traffic. My hope is if we have to give up the redirect to the tunnel this switch will keep users from being able to connect to one another. 

---

---

@kell490 wrote:

Option 2 is the only way to go have the guest vlan accross the uplink switch because if one excludes the guest vlan from the cluster users on the guest WLAN which is 70% of our wireless lan take as long as 20 seconds to fail over to the 2nd controller during reboots such as upgrades. It defeats the propose of having version 8 layer 2 cluster. What we have done in our test lab is setup the same as our Version 6 enviroment one tunnel from each cluster node using VRRP VIP address as the source. The master controller of the VRRP instance tunnel is UP/UP the back up controller is up/down. While I'm able to ping from the backup vrrp controller though the tunnel not exactly sure if I will be able to use firewall statement to redirct to the tunnel # when users are on the backup VRRP cluster node because were going to a cluster active / active controller enviroment. I will have to test this in the lab. 

 

My understanding that the firewall redirect to the tunnel # keeps users from being able to see other users on the guest wifi stops port scanners. We also enable the WLAN switch Deny inter user traffic. My hope is if we have to give up the redirect to the tunnel this switch will keep users from being able to connect to one another. 

---

 

We're also testing L2 GRE tunnels between 8.x clusters, so far initial testing is working. We have a tunnel from each of the 'remote' controllers to the VRRP IP of the 'main' cluster, then each of the controllers in the 'main' cluster has return tunnels to each of the 'remotes', but using the VRRP IP as the source. This allows each of the remote controllers to nail up a tunnel to the primary VRRP controller, while the secondary VRRP controller's tunnels are 'down' because it doesn't own the VRRP IP. 

 

In my case this is not exclusively for Guest to DMZ, we need it for situations where we need to span an L2 area to different buildings with different controller clusters.

 

I don't have inter-tunnel-flooding enabled, but I don't know if I need it yet, since the tunnel is only active on a single controller via VRRP? The tricky part might be if we add a third cluster to this setup.. 

 

Design attached that we came up with with our SE. Any thoughts welcome.

We ended up with having to setup a non routed vlan between the clustered controllers on the uplink switch which is the guest vlan. This way it insured no lost packets during failover testing.  I tested it with without the vlan we had packet loss during failover sometimes would not recover until client went back to the other controller.  I want to convert these to Layer 3 tunnels as some new Cluster I'm setting up can't use the same vlan ID as the others, but my downstream VLAN though our firewall is still using the other vlan. I think the L3 vlan might be better way to go breaks up the broadcast domain some.  Were on Version 8.5.x.x currently.

------------------------------
Kelly Levine
------------------------------

Original Message:
Sent: Dec 26, 2019 07:00 PM
From: Craig Monks
Subject: GRE tunnel between L2 clustered controllers Version 8

We're also testing L2 GRE tunnels between 8.x clusters, so far initial testing is working. We have a tunnel from each of the 'remote' controllers to the VRRP IP of the 'main' cluster, then each of the controllers in the 'main' cluster has return tunnels to each of the 'remotes', but using the VRRP IP as the source. This allows each of the remote controllers to nail up a tunnel to the primary VRRP controller, while the secondary VRRP controller's tunnels are 'down' because it doesn't own the VRRP IP. 

 

In my case this is not exclusively for Guest to DMZ, we need it for situations where we need to span an L2 area to different buildings with different controller clusters.

 

I don't have inter-tunnel-flooding enabled, but I don't know if I need it yet, since the tunnel is only active on a single controller via VRRP? The tricky part might be if we add a third cluster to this setup.. 

 

Design attached that we came up with with our SE. Any thoughts welcome.