Gargoyle Forum

Hi,

I've had guest networks on my Gargoyle router for a while, but no UI to set them up and I decided to remedy this yesterday. I added support for guest networks (if your wireless driver is MAC80211 or Atheros, though I need testers for the latter) to a clone of Eric's Github repository.

Right now, this is what I have. I can post some teaser screenshots tonight, though I do need some sleep...

• You can enable guest networking as long as you are in one of the AP modes. The guest network will use the same radio as your AP network.
• If you are in Dual Mode you have the option to only set the guest network on one of the radios so you can restrict your guests to a specific frequency.
• By default, guest networks have client isolation on. I was tempted not even to offer the option but I am happy that way; I believe in flexibility.
• The guest networks are isolated from the AP networks using ebtables as shown in this thread.
• The guest networks share the same DHCP server and range as the AP.

Just like for the main AP, if you disable guest networking and save, you have to redo all your config later if you re-enable it. I am not a fan of this behavior for both guest and for AP, so I may see if I can use guest networking as a playground for that. But only after I get all the basics tested thoroughly.

I am also looking for ideas of things that would be useful. I am sure someone is going to say QoS and quotas for guests. I see that some people set up a second DHCP server for their guests, but are there simpler ways to make it possible for guest traffic to be identified? I don't use QoS myself but I may be willing to trade a good tutorial as how to best use it for my own setup for some more features

You can find my fork of the code with the guest network feature here: https://github.com/yarrouye/gargoyle/tree/guest-network and I would love to see a few people give it a try before I do a pull request.

Here are a few screenshots of the UI changes I made. I hope this is (or will be once any kinks are ironed out) useful to some.

Thanks

but are there simpler ways to make it possible for guest traffic to be identified?

I have always thought a feature missing from gargoyle is "Rule groups"

e.g. You create a "group name" and assign a rule to it, IP address are then assigned to groups

Looks great. It'd be nice if you could also choose to tunnel guest traffic through TOR that way I don't have to be responsible for my guest's traffic.

doomguy2358753 wrote:Looks great. It'd be nice if you could also choose to tunnel guest traffic through TOR that way I don't have to be responsible for my guest's traffic.

I am not sure that obfuscating or hiding your traffic makes you less responsible for it, really... This being said, I do not use or plan to use Tor so someone else might have to look into this.

Once Eric release the BB based version of Gargole we can work on this feature. I have some ideas one how to make it possible to know which traffic is comming from the Guest AP.

Can you share your idea, pbix? I would like to play with QoS and guest. One idea is to run a multi homed DHCP server and then use the guest network's IP range to identify those clients. This would allow for example things like preventing them to connect to the router itself etc.

One thing I am not sure of is if one could have two different nets (say 192.168.1.0/24 and 192.168.2.0/24, one for wlan[01] and the other one for the matching -[01] for the guest interfaces! and have the same network 'lan' in their wifi-iface config? I think you or someone else mentioned on the guest SSID thread that for Gargoyle's QoS to work everything needed to be on the same network?

[Note, below is copy/pasted from my response to github pull request on this topic]

Thank you!

This work looks great -- probably something I should have implemented a while ago.

I will plan on merging this (and updating as necessary) into the new barrier breaker/1.7 branch once the basic port is done later this month. Yes, I know I said I'd have that finished early this month, but it is taking longer than I expected. The reason for the delay in merging is that since this is a fairly major new feature I would prefer to merge this into an experimental rather than a stable branch.

Great work. Looking forward to translate it when it will be merged.

Thanks Eric and thanks op this is a good idea.