wireless users

My wireless users are on a vlan. But the problem is currently they can access my internal network and I'd like to block that. I am not sure how I will accomplish this. The wireless users are connected to the APs and they are communicating with a controller. I was thinking may be this is the job of the firewall. But the wireless vlan is on the core and the core is doing the routing. So I am not sure how this will be done because the traffic will be routed before it hits the fw. So I am not sure how this will be accomplished.
Below is the high level setup. The internal network is not shown but it is connecting to the L2 switch.

fw<-->L3 WAN switch<-->core1<-->L2 switch<-->Meru controller

Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

gsmartinConnect With a Mentor Commented:
Meru networks controllers have the ability to securely tunnel traffic between the AP and the controller over an untagged/Native VLAN.  VLANs, as you mentioned, are configured on the controller either in a single interface or dual interface configuration.  

In a single interface config, you need to configure your management interface on the untagged/Native VLAN and then configure each of your WiFi Networks and associate them with their respective Security Profile, ESSID, SSID, VLAN, DHCP ServerThis problem could be caused by a number of issues. configuration. On the network side, the switch port will need the Native VLAN untagged, and all others tagged on the same port.

Dual port configuration, is similar to the above mention configuration with the exception of placing your external Internet bound VLANs on the secondary interface.  All internal WiFi VLANs will be tagged VLANs on the primary interface.  Also, make sure when using this configuration to first disable the default redundancy mode for the two interfaces.

Your guest VLAN can be placed on Firewall DMZ interface or on the outside interface like in my own configuration.  However, I leverage an additional NAT layer with a WAN aggregator.  This provides an extra layer and more flexibility for my needs.  In my case, I have a Guest WiFi SSID with an Open Captive Portal config and then a WPA2 Enterprise BYOD WiFi SSID with RADIUS authentication.

In your case, NAT'ing the Guest VLAN network off your Firewalls DMZ is usually the recommended placement.

From a security perspective, using the encrypted Tunnel is the preferred/recommended configuration to secure your traffic with either the single or dual interface configuration.
I'm assuming this wireless is for guests?  Otherwise, I do not understand why you would allow your users to connect wirelessly but not access the network.

If it is for guests, then you need to put the AP on a guest VLAN that is segregated from the internal network.
leblancAccountingAuthor Commented:
Sorry. Yes it is the wireless guest users and it is in vlan 50. The APs are communicating with the controller at layer 2. You don't configure VLAN on the APs.
Will You Be GDPR Compliant by 5/28/2018?

GDPR? That's a regulation for the European Union. But, if you collect data from customers or employees within the EU, then you need to know about GDPR and make sure your organization is compliant by May 2018. Check out our preparation checklist to make sure you're on track today!

gsmartinConnect With a Mentor Commented:
FYI.... In my environment, all mobile (iPhones, Androids, iPads, Tablets, etc...) and other device (BYOD) non-corporate wireless systems have external internet access.  They can only access internal resources via an external SSL Citrix VPN tunnel; assuming they are permitted to access internal resources.
gsmartinConnect With a Mentor Commented:
Now to get to the point....

On your firewall you should be able to add VLANs.  Added the Guest WiFi VLAN and subnet with the respective firewall NAT, ACL, and routes from the DMZ interface.  If you have an available firewall interface you can configure appropriately as a tagged or untagged VLAN.  Otherwise, you will need to modify by tagging (or combination of untag and tagged) the firewall DMZ and associated switch port with the current and new Guest WiFi VLAN.  Therefore, your Guest WiFi traffic would be routed via your firewall from the DMZ.

If your are using Cisco switches, your Native VLAN is untagged traffic and all other VLANs are Trunked typically using 802.1q/DOT1.q.  Other switches will use untag and tagged.  You can only have one untagged VLAN on an interface , which referred to as Native or Default.  Where as, you can have multiple tagged VLANs on a single interface.

I don 't know the extent of your knowledge so I went ahead and went a little more in-depth.
Craig BeckConnect With a Mentor Commented:
Taking the guest traffic to a dedicated firewall is the way to go, as gsmartin is suggesting, but if you don't have that at the moment you might as well forget about talking about what you could do with your VLANs, etc.  You already have a guest VLAN, so that's a start.  It's nothing to do with native or tagged VLANs though.

The router which separates the guest subnet from the corporate subnet(s) should be able to use access control lists (or rules) to stop guests from being able to get to certain other subnets or hosts.  Just create a rule which allows guests to everywhere apart from your corporate subnets.
gsmartinConnect With a Mentor Commented:
Craigbeck's approach is certainly another option.  However, I disagree with the Native and tagged VLANs.  Your default Native untagged VLAN for the primary Meru controller interface is used for management traffic between the controller and APs.  Now depending on the number of interfaces you have and SSIDs that line up with your internal and external networks/ VLANs will determine your needs from a wireless architecture and tag/untag perspective.  

Configuring your router with ACLs is certainly an approach for very small environments.  And, depending on your internal segments and number of router interfaces will also determine if you need to extend a 802.1q trunk to your router; again this may potentially involve tagging.

FYI... The majority of networks these days have firewalls.  

My preference is to keep all guest insecure laptops, mobile and other BYOD devices outside of the corporate network; irrespective of router ACLs.  Your wireless architecture will vary depending on your overall corporate network architecture.  So either solution provides you with options.  

The Meru Controller and guest wireless network happens to be a very relevant question for me.  Since the last couple of weeks I've been doing a POC with Meru's 1550, 3200, and virtual appliance controllers along with some AP832 802.11ac access points to potential replace our Cisco wireless network.  

So respectfully, we chose a configuration that best suits our corporate requirements, network and security architecture/topology.
Craig BeckConnect With a Mentor Commented:
Your default Native untagged VLAN for the primary Meru controller interface is used for management traffic between the controller and APs.  Now depending on the number of interfaces you have and SSIDs that line up with your internal and external networks/ VLANs will determine your needs from a wireless architecture and tag/untag perspective.
I think you misunderstand what I'm saying.

VLANs and tagged/untagged VLANs are relevant - that's for sure.  What I'm saying is that tagged/untagged VLANs are irrelevant when trying to stop traffic from one VLAN from seeing traffic from another VLAN.  What you need to do to stop inter-VLAN routing is to use a firewall or ACL.  That's a Layer3 function, not a Layer2 function.

Layer2 VLANs only provide the boundary between subnets (for example).  They don't provide an absolute way to stop traffic being routed.  Also, there's no difference between a tagged VLAN and an untagged VLAN apart from that any traffic which isn't tagged goes into the untagged VLAN.  Tagging a packet with a particular VLAN ID doesn't do anything more than specify which VLAN the packed should be placed into.  What happens after that is outside of the Layer2 boundary and moves up the OSI model to Layer3.

So, yes you need to separate Guest traffic from Corporate traffic using Layer2.  The OP suggests that this is already the case though and quite obviously that isn't stopping Guests from seeing Corporate resources.  Therefore a Layer3 (or above) solution is also required to further restrict traffic between the VLANs.

The point here is that there is no DMZ solution and ALL WLANS from the Meru controller originate inside the Corporate LAN.  That information is vital to understand what is already configured and what can be done to achieve the requirement.

In a Cisco environment it would be easy to secure this using a Guest Anchor controller inside a DMZ.  That would absolutely secure the Guest traffic inside an EoIP tunnel to the DMZ.  However that obviously requires another controller (and maybe another firewall).  In other vendors' implementations though this isn't always possible and a whole different approach is required by using a different router/firewall on a specific Guest VLAN which is inside the Corporate network.  This approach is less secure but it's often the only way to do it.  This is what should happen in this scenario, but if no other firewall/router is appropriate the current router should implement ACLs/Firewall rules if it can.
Rick_O_ShayConnect With a Mentor Commented:
I would think the simplest solution would be with an ACL inbound on the routed interface of the wireless VLAN. Or better yet via a simple policy on the controller itself for that traffic which would be before it actually leaves the "wireless" side of the network.
Craig BeckConnect With a Mentor Commented:
@Rick_O_Shay - exactly my point.  I don't think the Meru controller will do ACLs, hence the suggestion to do it at L3 on the upstream router.
leblancAccountingAuthor Commented:
I will test it next week. Thx
gsmartinConnect With a Mentor Commented:
The below Meru diagram describes the typical controller Corp-Guest wireless topology for most small networks and is similar to your architecture.  This is not the architecture I've been referencing.  This is a simple internal Layer 3 configuration, which would require L3 router and ACLs to isolate the traffic.

Single Interface Corp-Guest VLAN Example
Single Interface Corp-Guest VLAN Example
Therefore, I described an alternate configuration used a lot of medium-to-large corporate networks or even some smaller SMB companies such as mine.

So, I will reiterate my point, but first I will address the reference regarding ACLs on the Meru Controller. Yes, Meru does not support ACLs nor does it need to.  In a single or two interface configuration Meru tunnels traffic from the AP, with built-in TLS-VPN encryption, to the respective interface.  So, effectively the Guest VLAN traffic is secured and isolated going through to the second Meru controller interface on the outside of the network.  The Guest VLAN is not configured on any portion of the inside network especially for L3 routing on the internal router.  It is only configured on the Meru Controller secondary interface (Interface index 2) and on a switch port for either the external network or DMZ that can be NAT'd with a non-routable subnet.

Yes, I'm aware this is not how the network is currently configured.  My point is to provide a solution that appropriately separates the Internal/Corporate and External/Guest traffic.

Having said that, below is an example of the configuration I've implemented in my Meru POC; however, my configuration is a little more elaborate that includes multiple Internal/External wireless networks.  Externally, I've setup Guest, BYOD, and Mobile VLAN networks with either Captive Portal or RADIUS authentication along with a few internal VLANs on the primary controller interface.  The controller interfaces are divided between Internal and External VLANs.

Note on your L3 switch that connects to your firewall you can also configure L2 VLANs for the outside network.  This may depend if you have an external router beyond your firewall, which I have in my case.  

Two Interface Corp-Guest VLAN Example
Two Interface Corp-Guest VLAN Example
I know this may be more elaborate than your network.  The point is to educate you on your options, and depending on your network architecture or Firewall DMZ capabilities could be a possible solution to implement vs internalizing the traffic.  With this configuration the untagged and Tagged (Cisco: Native, Access, and Trunk) VLANs is relevant in either case.

I've also included the Meru Networks documentation that covers either configuration.
Craig BeckConnect With a Mentor Commented:
I see where you're coming from @gsmartin.  There's one big problem with that though...

If you have a 1550 controller that means you only have 2 ports to connect to the network.  Would you 'really' want to use one of your ports just for guest traffic, and sacrifice redundancy and bandwidth for your corporate clients?  I'll guess not, so your guest traffic WILL be traversing your internal network in some form.

My point was that if your interfaces come back to your corporate network (inside the firewall which doesn't bridge VLANs) you 'have' to use an ACL somewhere to keep the guest traffic away from the corporate traffic, whether that's at an upstream router or firewall.

The solution is to stick a separate router/firewall on the guest VLAN which only connects to the internet - as we've both already said.
gsmartinConnect With a Mentor Commented:
Regarding the issue with my recommendation.  Either approach is obviously debated able.   So the points /concerns are with having Guest WiFi traffic on a dedicated controller interface, occupying bandwidth and reusing secondary interface for redundancy.

With this you need to qualify and get a better understanding of the volume and types of traffic. First, you need a good understanding of who and what devices are considered guests, mobile devices, BYOD (if used). Vs internal traffic.  If you allow mobile devices to connect to your network hopefully they are placed out on the outside given their security vulnerabilities.  These devices are either guests that use captive portal with local authentication, or corporate Mobile devices using radius with AD.  The point is by separating the wireless traffic.

Second, I would question what degree of redundancy and/or HA is commonly implemented through out the network.  If there's a big investment then I would say you may have a point.  Otherwise, then it's not as critical.  There can be a very big price tag with redundancy and HA, which typically is a business decision. When these questions are asked then need to define what degree of redundancy or HA availability is necessary or required; which depends on how the company is willing to invest.  This is typically very costly.  

If the company doesn't invest a lot in redundancy then I wouldn't consider it.  I think by seperating the traffic, especially if you have other uses like mobile and BYOD devices externally on either the Guest or other wireless network then that should be enough volume to separate the traffic.  More importantly, from a security stand point it would be preferred as the Meru two controller interface example depicts.  Personally, I prefer separating the interfaces for internal/management and external traffic.  For redundancy, I would have an HA controller configuration.

Note you would need to remove the internal L3 inter-VLAN routing for the Guest VLAN and relocate elsewhere once outside the firewall.

But of course, this may be a big problem for some!
Craig BeckConnect With a Mentor Commented:
You don't need to tell me any of that - I design Cisco Wireless solutions for one of the biggest Cisco partners in the world.  It's handy for the author to bear in mind though :-)

I suppose it depends on the rest of the network, but I'd not want to dedicate 50% of my total connectivity to a guest service, unless it was predominantly for guest usage.  Don't forget, we have to work with what we've got.

If the network isn't that extravagant I'd question why, then suggest (based on the assumption that it's not an ultra-secure network) that it's acceptable to use Layer2 to isolate the Guest service using the existing topology, and use ACLs at the firewall/router to block inter-VLAN traffic.  In an ideal world this traffic would be completely separate though and would come from an independent interface on the WLC, but I'd prefer the best of both worlds unless it's absolutely vital that the risk is mitigated :-)

I would probably also go a bit further and suggest that if possible the existing network doesn't have a routed interface or SVI on the Guest VLAN, and that instead a separate router/firewall is used to take traffic away from the network.  This is an acceptable approach when the DMZ solution isn't available and is 75% of the way to what you said, gsmartin, except you're not using a dedicated interface for the guest traffic.
Craig BeckCommented:
I suppose though I should say that gsmartin's solution is a completely valid one :-)
All Courses

From novice to tech pro — start learning today.