Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

Let's say I have a subgroup of users on a LAN, and I want them to have access to the Internet but not to any of the other nodes on the LAN other than a default gateway, and ideally no access to each other either. What's the cleanest way of doing this?

1. I could perhaps do it by firewalling off IPv6 and IPv4 to explicitly forbid access to address ranges, but I suspect that that has big holes in it, for example, use of non-globally-routable address ranges and ::1.2.3.4, say, to get to other nodes by alternative addresses.

2. A rather worse hole here is the use of non-IP Ethernet frames. The sending of any Ethernet frames to nodes outside the designated group (again, other than the default gateway) is to be prohibited.

3. However, isn't there also some smart way using VLANs?

4. Using a NAT translator and splitting the LAN entirely might be another possibility, but this again would need additional firewall rules which I am not sure how to write, and kind-of brings us back to 1.

[aesmith]

I would deal with this by creating a separate VLAN for these devices, with a separate subnet.   

Depending on the capabilities of your switch you may be able to create this as a "private" or "secure" vlan (terminology varies between vendors) with only the port connecting to your firewall/router as promiscuous.  That configuration prevents traffic at Layer 2 from passing between clients, limiting it only to client <-> firewall.

Again depending on your firewall, either create specific rule permitting traffic to pass only between this vlan and the outside interface, or create an access control list blocking access to your internal ip range(s).

Non-IP frames shouldn't be a concern, as the firewall interface should be acting as an IP router, so will ignore anything non-IP.

[BigBunny]

I agree with aesmith and use vlans.  It is by far the easiest and in most cases the most effective way of setting up segmentation.  If you are not sure how to go about this have a look at the Netgear site.  They also had at one time a FAQ on different ways of going about this.

[Weaver]

I'll take a look at the Netgear site.

@AESmith thanks. It will take me some time to research this and see if the Firebrick can handle this or whether I need more hardware.

I've thought of another problem. If some of the isolated clients are on a WLAN I will need to make sure that the WAP can handle the case of forbidding inter-client communication. I will try and find out if the Zyxel NWA3560-n can do this, as I have several of these devices already.

[burakkucat]

I've thought of another problem. If some of the isolated clients are on a WLAN I will need to make sure that the WAP can handle the case of forbidding inter-client communication. I will try and find out if the Zyxel NWA3560-n can do this, as I have several of these devices already.

The key words for your search should be "client isolation". All reliable WAPs, these days, will have such a configuration option.

[Weaver]

It turns out that one of my WAPs can do inter-client isolation on a guest SSID, and possibly can do everything I want, even mapping the traffic from the isolated nodes to a VLAN. I don't know how DHCP is supposed to work in the face of all that. And I don't know if IPv6 will be happy, can soon find out. I don't know how I'm supposed to handle this lot at the Firebrick (router=Internet gateway node) end, at a minimum I need to remap the isolated VLAN to something suitable so it can go out the door.

[aesmith]

Do you do DHCP from the firebrick?

Proper access point "guest" SSIDs tend to work in one of two ways.  At the simplest they offer a separate SSID, allowing you to set different security and client isolation, and mapping onto a separate VLAN so you can set different policies on the wired LAN.

Some do it a bit differently by creating the whole guest network inside the AP, for example Meraki do it that way.  In these cases the AP looks after everything, IP addressing, NAT, firewall etc, and only compliant packets are allowed out onto your LAN.

Assuming your AP is of the first sort, you could you configure a separate VLAN for the guest WLAN, and connect this to a separate L3 interface on the Firebrick.  Separate DHCP scope keeping all guest stuff away from your own network.  Then you'd need rules on the Firebrick permitting that network Internet access only.

[Weaver]

> Do you do DHCP from the firebrick?

Yes. For IPv4. Not for IPv6, yet, unfortunately. IPv6 devices just get RAs from the FireBrick to give them the global prefix and then spin an address using one of the usual standard mechanisms, but I don't do IPv6 yet.

> Proper access point "guest" SSIDs tend to work in one of two ways.  At the simplest they offer a separate SSID, allowing you to set different security and client isolation, and mapping onto a separate VLAN so you can set different policies on the wired LAN.

Which is what I already do with my Zyxel NWA3650-n, except that I haven't sorted out the VLAN handling yet. It can tag packets with a tag if your choice, by the look of it. But I don't know what to do with that at the Firebrick end. (Firebrick speaks VLANs to some extent, an _interface_ can be associated with a VLAN tag value.)

> Assuming your AP is of the first sort, you could you configure a separate VLAN for the guest WLAN, and connect this to a separate L3 interface on the Firebrick.  Separate DHCP scope keeping all guest stuff away from your own network.  Then you'd need rules on the Firebrick permitting that network Internet access only.

Which is where it all falls apart for me. :-) I'd need to get some serious Firebrick support for this, which I can do, the generous support you get from Andrews and Arnold (who I bought the FB from)  is good.

I currently apply 'firewall' rules to IPv4 packets in the guest range to rate limit the traffic coming in to those addresses, so guests can't hog the Internet, not unless they are smart enough to use IPv6 anyway, and seeing as that is browsers' default nowadays, then this is a serious flaw in this plan.