Can Guest WiFi Use GRE Tunnels to DMZ Access Points?

  • 2
  • Question
  • Updated 4 years ago
  • Answered
  • (Edited)
I would like users connecting to my Guest SSID to be tunnelled to APs in my DMZ. However, I have a single Wireless DMZ with a couple of AP's. I am using an external DHCP server for my guest hosts. As long as I use a single Tunnel policy and user profile/vlan, the guest access works fine.

However, I would like to assign different VLANs/IP subnets to my Guest users accessing the wireless network at different branches while still being tunnelled to the same set of DMZ AP's at my corporate Data Centre to go out the single Internet connection we have for this purpose.

I can't find any useful documentation on doing this. Would appreciate some help.

Thanks,

Mag.
Photo of mag007

mag007

  • 24 Posts
  • 1 Reply Like

Posted 5 years ago

  • 2
Photo of mag007

mag007

  • 24 Posts
  • 1 Reply Like
Would like to add that the Guest SSID has to be the same across all locations.

Thanks
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
mag007,
I'm not sure I understand what you're trying to accomplish. The guest users should be given IP addresses suitable for that DMZ and to be placed in VLANs associated with that DMZ, why do you want them to get separate subnets based on which branch they're coming from?
Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
Since the GRE tunnel provides layer 2 connectivity between the clients on the SSID and the DMZ, we will pass a VLAN through the tunnel. If you have different VLANs assigned for guests at different branches, we can pass those through the tunnel. You'll need to have the network set up to support those VLANs (trunk ports, DHCP services) on the DMZ side.

We have some training slides that might be of use, which I can unicast to you via email if you like. Please send an email to community@aerohive.com with your contact info, and we can get those slides over to you.
Photo of mag007

mag007

  • 24 Posts
  • 1 Reply Like
Apologies for the ambiguity. I guess I am having problem placing guests from different locations in different VLANs associated with the DMZ.

Another way to put the question:
Site A: I have APs in three subnets
Site B: APs in a single subnet
Single DMZ at Site A with two DMZ APs.

Need all guest traffic to be tunnelled to the DMZ such that guests from each subnet at Site A and Site B are assigned a subnet of their own in the DMZ.

Two reasons for doing this:
1. Quickly identifying which site/location the client is coming from.
2. To a lesser degree, improve performance by not making the guest subnet/vlan span the entire campus.

Hope this is clearer.
Photo of mag007

mag007

  • 24 Posts
  • 1 Reply Like
Thanks Andrew. I guess training slides would be helpful but I was hoping that with so many features, Aerohive might have come up with something like "Advanced Configuration and Deployment Guide".

Anyways, the trouble point is that do I need to define the Guest VLANs on the wired side in my Internal network? My understanding is that the Wireless guest clients are tunneled to the DMZ where the VLANs and DHCP services exist.

I don't want the guest users to have any connection to the Internal wired network.

My test setup involved two VLANs at DMZ side, trunk ports from DMZ APs to my Firewall. DHCP services running on the firewall for the two VLANs.

For some reason, I was only able to get clients assigned an IP address from one VLAN only and this was the VLAN that was tied to relay policy using MGT0 interface. If I assign VLANA in this guest policy, VLANA would work and VLANB would not work. If I assign VLANb to this relay, VLANA would not work.

I also created subinterfaces on DMZ APs for the VLANB, but I suppose that does not have effect. Also, we cannot terminate tunnels on subinterfaces.
Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
Hi mag007,

I just set this scenario up in my lab, which I think reflects the scenario you are describing, using 5.1r4a. The key is to use Classifer Tags to assign different VLANs to Guest users, depending on the AP they are connected to. You would set Classifier Tag1 = Site1 or Site2, etc on each AP, depending on their source network. Classifier Tags are configured by modifying each AP's settings, and Classifier tags may be found there under Advanced Settings.

GRE Destination/DMZ: AP330
IP Address = 10.5.1.40/24
This AP is on a VLAN trunk that supports VLANs 1,8,10.
DHCP services are configured for each VLAN
VLAN 1 = 10.5.1.0/24
VLAN 8 = 10.5.8.0/24
VLAN 10 = 10.5.10.0/24

Subnet 1: AP141
IP address 192.168.100.2/24 (DHCP)
Classifer TAG1 = Site1 (set on each AP in the subnet)
Clients that connect here will be assigned address in 10.5.8.0/24

Subnet 2: AP121
IP Address 192.168.101.2/24 (DHCP)
Classifier TAG1 = Site2 (set on each AP in the subnet)
Clients that connect here will be assigned address in 10.5.10.0/24

SSID – Guest
Encryption: Open
Captive Web Portal: Use Policy Acceptance
User Profile: Guest-Users (Attribute 100)
- VLAN-only Assignment = GUESTVLANs
o VLAN 8 - Type Classifier Tag1 = Site1
o VLAN 10 - Type Classifier Tag1 = Site2
o VLAN 1 -Type = Global

- GRE Tunnel Policy = GuestTunnel
o Enable Static Identity-based Tunnels
o Tunnel Destination = 10.5.1.40
o Tunnel Source = 192.168.100.0/24, 192.168.101.0/24
o Tunnel Auth password -- GENERATE
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
I know a number of people new to Aerohive have issues with classifiers and what they actually do so here is an example I use to describe them:

You have access points in three offices (Dublin, New York and Liverpool) and you want the local users to have access to servers in their office but not the other offices. The subnets are 10.100.100.0/24 (Dublin), 10.100.200.0/24 (New York) and 10.100.300.0/24 (Liverpool).

To advise each access point as to where they are located you can use the device classification tags (Monitor -> Aerohive APs -> [Select all the Dublin APs] -> Modify -> Advanced Settings). In the "Tag1" field enter "Dublin" being careful as:

* The tag values are case sensitive, so "Dublin" is different to "dublin".

* A space at the end of the data will be counted as part of the tag so be careful to ensure that you don't enter "Dublin[SPACE]".

Click on the "Save" button. The Tag1 value for each of the Dublin APs is now set to "Dublin".

You now repeat the process for the New York and Liverpool APs setting their Tag1 values as "New_York" and "Liverpool".

Now we need an IP object that references the three server subnets. Click Configuration -> Advanced Configuration -> Common Objects -> IP Objects/Host Names -> New. Change the IP object type to "Network" and enter "Server_Subnet" into the "Object Name" field. In the "IP Entry" area enter the Dublin subnet into the "IP Address" and "Netmask" fields and click on the "Type" drop down menu. Change it from "Global" to "Classifier", enter "Dublin" into the "Tag 1" field and remove the ticks from the "Tag 2" and "Tag 3" fields. Enter "Dublin Server Subnet" into the "Description" field and click on the "Apply" button.

You will notice that the "Value" field now says "(T)tag1=Dublin;(F)tag2=;(F)tag3=". This means that when the classifier is analysed only the "Tag 1" field will be evaluated - T=True F=False.

Repeat the process to enter the Liverpool and New York server subnets ensuring you get the tag values perfect.

Each IP Object must have one Global value. When classifier values are used in an IP Object the Global value is used when none of the classifier values are evaluated as true. For example, if an access point had a "Tag 1" value of "Galway" then the Global value would be evaluated as true as the "Tag 1" value is not "Dublin", "Liverpool" or "New_York". As a rule of thumb I tend to use non-routable addresses as Global values when I am using classifiers. For example, you could use the subnet 2.2.2.2 255.255.255.255 (really a host) as the Global value. This means that if the user is connected to a misconfigured access point they will not be granted access to an incorrect subnet and the 2.2.2.2 255.255.255.255 address will be easy to spot in the fault finding process.

You can now use the "Server_Subnet" IP object in firewall rules such as:

permit all Server_Subnet all

By setting the firewall policy "Default Action" to "Deny" you will stop users being able to access the server subnets at the other offices.

When the configuration is pushed to the access points the HiveManager will see the classifier and evaluate the correct subnet for the firewall rule. So if you pushed the config to all the access points and then made a SSH connection to the access points you would see the firewall rule is different in each location's access points:

Dublin access points - permit all 10.100.100.0 255.255.255.0 all
Liverpool access points - permit all 10.100.200.0 255.255.255.0 all
New York access points - permit all 10.100.300.0 255.255.255.0 all

So what is important is to remember:

* Classifiers only exist in the Hive Manager and the correct value is "inserted" into the access point configuration when it is pushed to the access point.

* If you are having issues with your classifiers SSH into the access points and check their configuration as it will commonly show you what is wrong with the classifier. Always look for the Global value in the appropriate section of the access point configuration.
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Crowdie,
I wish I could have given you two stars for such a well-written and easy-to-understand explanation. Good job.
Photo of mag007

mag007

  • 24 Posts
  • 1 Reply Like
Thanks Andrew and Crowdie for your detailed replies. I was using Classifiers on the DMZ side but was using different profiles (per subnet) on the Internal APs.

I will test out as per your scenarios and test. The clarity of your replies gives me confidence that it will work.

Thanks,

Mag
Photo of mag007

mag007

  • 24 Posts
  • 1 Reply Like
Hi All,

Sorry for the late reply. The Guest scenario with classifier based vlans works perfectly.

Thanks Andrew and Crowdie.

Mag.
Photo of mag007

mag007

  • 24 Posts
  • 1 Reply Like
Hi All,

It is kind of frustrating after getting such good advice and have everything working and yet to see everything seem to fall apart.

I had the scenario working perfectly with two test AP's to two DMZ AP's. However, when I deployed the policy to large number of AP's, now I cannot seem to connect to my Guest SSID. I can connect to my DMZ AP's on that SSID but not on my internal APs. Firewall has full ip level connectivity between internal AP's, hiveManager, and the DMZ AP's. It seems like the GRE Tunnel process is failing, because I don't see any tunnel attempts.

Can't figure out what could have broken it! All suggestions welcome.

What I do see is a lot of chatter between my internal APs and the DMZ APs. I sniffed this traffic and it relates to the DIS (Distributed Interactive Simulation) protocol. I don't think the amount of this type of traffic is normal.

Any ideas?

Thanks,

Mag
Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
WIthout knowing more about your network topology, how many APs you are talking about, or how and where you tested the solution, I can offer a couple general suggestions:
1) Make sure you added the source addresses/networks of all your APs to the tunnel policy;
2) If the remote sites are behind a firewall or router doing address translation, make sure the tunnel policy reflects as the sources the public IP addresses of the APs, not the private addresses.

Moreover, I suggest you open a case with our support team. You can create a support ticket at http://support.aerohive.com/support/l....
Photo of mag007

mag007

  • 24 Posts
  • 1 Reply Like
Thanks Andrew.
I have about 350 APs in production and 2 in dmz.. I have enabled NAT exempt on my firewall to allow these devices to communicate without NAT translations.

All the requirements that you mentioned gave been satisfied.

I have removed my guest ssid from all APs and basically started from scratch but now i cannot seem to connect with the test AP scenario that was working before.

BTW, with just one AP, i am atleast able to see that the gre tunnel is forming on the internal ap. But no dhcp request is seen in the dmz zone so my client cannot get ip address.

I will open case, do more troubleshooting and update here.

BTW, i saw one aerohibe guide/document regarding the ports that need to be open through firewall but that was not accurate. I had to open ipip yo make ot work the firsy time. If a definitive list of ports is available, would like to consult that.

Andrew, how can i get those slides that you mentioned at yhe start of this thread?

Regards,

Mag
Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
Hi Mag,

I've provided much more specific instructions than the training slides will, but I can still send them your way if you like. Please send your email address to community@aerohive.com, and I can forward them to you.

I hope you've been able to get your problem sorted out through support in the mean time.

Andrew
Photo of Matthew Rudkowski

Matthew Rudkowski

  • 38 Posts
  • 2 Reply Likes
@Andrew Garcia, would you happen to have these slides still, or any updated documentation in regards to GRE tunnels to a DMZ using the CVG as the termination point? (Strictly layer 2 for a guest SSID) I am facing this same issue as many of our remote sites are only on private connections and will need to be tunneled back to our HQ in order to provide guest inet-only access.
Photo of mag007

mag007

  • 24 Posts
  • 1 Reply Like
into the problem, looking for additional information.

I am engaged with our Aerohive partner but so far they have been of little help. However, I have been able to wipe clean a couple of APs and start over and managed to get tunnel up between a single internal and dmz AP using a single (same) policy.

I cant seem to get the tunnel working if the guest ssid profile and/or associated user profile are different between the internal and dmz APs, even when they use the same ssid and tunnel policy. Is it a requirement that internal and dmz APs must use the same ssid profile, user profile, etc. I mean the policy on internal APs contain additional ssids not present on the dmz AP.
Photo of mag007

mag007

  • 24 Posts
  • 1 Reply Like
Thanks Andrew. I am very satisfied by your answer. I thought about the training slides only after runninginto the problem, looking for additional information.

I am engaged with our Aerohive partner but so far they have been of little help. However, I have been able to wipe clean a couple of APs and start over and managed to get tunnel up between a single internal and dmz AP.

I cant seem to get the tunnel working if the guest ssid profile and/or associated user profile are different between the internal and dmz APs, even when they use the same ssid and tunnel policy. Is it a requirement that internal and dmz APs must use the same ssid profile, user profile, etc. I mean the policy on internal APs contain additional ssids not present on the dmz AP.
Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
I only set up my testbed with a single SSID and user profile at all APs initially, so I will look into whether those objects need to be the same on both sides.

In the mean time, I'm not sure you are aware of this, but we have the ability to turn off SSIDs on selected APs. If there are SSIDs in your policy that you don't want advertised in your DMZ, you can turn off those SSIDs on the device settings page.

If you go to the DMZ APs and Modify, under Optional Settings > SSID allocation, you can turn off SSIDs on a per radio basis.

I know it's not the answer you are looking for, but it is something to play with while I try to find your answer. :)
Photo of Scott M.

Scott M., Sr. Support Engineer

  • 104 Posts
  • 8 Reply Likes
Yes, this should be possible using an L2 GRE Tunnel in conjunction with User Profiles.

I made the diagram below in an effort clarify and aid discussion.

Photo of Mohanantass

Mohanantass

  • 45 Posts
  • 0 Reply Likes
Does aerohive have any configuration guide for this guest tunneling.
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Do any of the videos here help you? http://www.aerohive.com/330000/docs/h...
Photo of Mohanantass

Mohanantass

  • 45 Posts
  • 0 Reply Likes
Thank you mike.. will use that..

Mohan
Photo of mag007

mag007

  • 24 Posts
  • 1 Reply Like
I had not updated on the outcome of working with Aerohive support, here it is.

The problem I encountered had to do with limitation on the number of tunnels that a physical AP would support, hence when I rolled out the Guest Wifi to all AP's, it stopped working.

The solution is to use Aerohive's Cloud VPN Gateway (CVG) virtual appliance.  The appliance supports 1500 tunnels and therefore is a more robust solution for larger deployments.

I think the tunnel limitation on a Physical AP is about 160.

Mag
Photo of Matthew Rudkowski

Matthew Rudkowski

  • 38 Posts
  • 2 Reply Likes
Thank you for the update Mag. I am just beginning my deployment and plan to roll aerohive out to over 350 of our locations across the WAN, with most sites our only option for guest will be to tunnel back to a DMZ.  Did you ever receive any updated documentation for this configuration using the CVG? 
Photo of Amanda

Amanda

  • 396 Posts
  • 25 Reply Likes
Hi Matthew - I checked around and think this documentation should help you out. http://www.aerohive.com/330000/docs/help/english/6.1r5/hm/full/help.htm#config/com/tunPol.htm

amanda