Experience with Intellinet Guestgate Hotspot Gateway

We recently acquired an Intellinet "Guestgate" Model 523240 hotspot gateway, which is intended to allow shop owners and other naive operators to offer visitors a connection to the internet without exposing their internal LAN to strangers with laptops. There is relatively little explanation in the marketing materials of just what the device does, so I thought I would describe our initial experience here for any interested person. Intellinet have managed to create something that is usefull even with no setup, and probably even in the hands of an uninformed user.

Physically, the device is just a cable/dsl router/switch with slightly different firmware. There are five ethernet ports, one labeled "host" and four labeled "guest". The idea is that you plug the host port into your LAN (on the inside of your firewall) and plug the guests or an unsecured wifi access point or router into the guest ports. The device acts as a dhcp client on the host side, and a dhcp server on the guest side, and NATs between the ports. The clever part is that it uses the gateway address and network mask from the dhcp server on the LAN (the host side of the Guestgate) to discriminate between packets destined for the wider internet beyond your gateway (which are allowed) and packets destined for devices on your LAN, (which are dropped). So the guests are effectively restricted as if they were outside your network and with no access to devices inside your network. This is the default configuration, and the device requires no setup if this is satisfactory, as it likely will be if you don't run servers on your LAN, or need to support guests using protocols unfriendly to NAT. This much seems to be very well done. No setup is so much better than a GUI setup.

I would have expected that by now this would be an option in standard commercial wi-fi routers, but it is not, nor is it possible to simulate this with any combination of settings in the home routers I have seen from Linksys, Netgear, Dlink, etc.

I should add that nameservice requests are allowed to whatever nameservers are suggested by the LAN dhcp server, even if within your LAN. That seems quite reasonable. There are no doubt networks where this separation will not be sufficient to protect inside assets, but anyone operating such a network probably knows enough to recognize the potential problems.

The device normally assigns guests IP addresses from the 172.16.0.0/16 RFC1918 space, but if a guest uses a different address, that is accepted. Apparently the NATing still works, as we haven't had any complaints, but it seems an odd thing to do. It does allow guest computers with fixed IP addresses to access the internet, but I would worry they might interfere with each other, or not have access to servers on their home network. Again, we have had no complaints, so perhaps this is a non-problem. It would be nice to have an explanation of how this works. [Note added November 2008 - we are starting to recieve complaints of "another host has this IP address"]

A wi-fi access point can be connected to one of the guest ports without any setup - the Guestgate will provide IP addresses to clients, and sufficient security to protect the LAN (if not the client). The Guestgate manual suggests that since the Guestgate assigns each client an IP address in a separate network, the clients can't interfere with each other. That seems optimistic as a security measure, but it may prevent accidental undesired communication among guests.

You can also use a cable/dsl router with wi-fi, provided you either turn off the dhcp server or connect the Guestgate to the WAN port on the wi-fi router. Double NATing does not seem to cause any problems, and wi-fi routers are much cheaper than access points. Probably turning off one of the DHCP servers and connecting the Guestgate to one of the switch ports on the wi-fi device is the right way to do this.

Options

There are some options that can be set, but the typical user will have trouble getting to them. This is because they can only be set with a browser on the host side of the box. The manual (provided in 10 languages, but largely devoid of information) suggests searching the dhcp server logs for the Guestgate MAC address, and using a browser to access the associated IP address. Even assuming a naive user managed to find the dhcp server logs, contrary to the manual the Guestgate MAC address is not printed on the base of the unit. I was able to get the MAC address with a "tail -f" on the leases file.

If your network has no dhcp server, the host side of the device defaults to 192.168.2.1, and the manual has several pages describing how to change the IP address of a Windows PC to accomodate that and gain access to the http setup screen. (Where a more suitable static IP address may be assigned). This would be a little smoother if they moved the setup http server to answer on the guest ports, so the dhcp server in the Guestgate will control the IP address of the browser client, Then getting to the setup page will be straightforward - just specify 192.168.2.1 in the browser address bar. This might require https for security reasons, but would be considerably simpler.

In the default setup access to the Internet is enabled only after the guest has clicked through a welcome screen. This can be turned off, so that non-web access is not broken, or the welcome screen modified, or you can specify a single guest password.

Maximum host network bandwidth for the device can be set, but you can't set a time limit for individual clients, such as a cafe might want.

Trusted Ethernet MAC addresses can be specified, but what additional rights are given to those addresses is nowhere specified - it may have to do with bandwidth, but may not.

On the Packetfilter page you can specify blocked addresses (by host IP or network), blocked ports, and permitted addresses (by host IP or network), but what happens if you make entries in more than one ruleset is not apparent. You can also specify "Walled garden addresses" but there is no indication of what that might be, or how it would interact with the other rules. We were disappointed that we could not allow ssh (port 22) access to hosts our LAN, while disallowing other access. This was because there is no "allow ports" rule available, only "allow host". We use that to allow access to our webserver and for users to tunnel to X-windows clients.

The default password is "1234", it's in the manual, not on the device. There is a reset to factory defaults button. Write the default password on a sticky attached to the device if you plan on losing the manual.

For reasons unclear to me the Guestgate operates a caching DNS server available from either side, and an additional http server (for setup) at port 81 on the host side. NMAP suggested the OS might be Solaris, which seemed pretty unlikely, however SUNs Cobalt servers are said to use port 81 for an administrative interface, and I suppose anything is possible.

While I have wondered why (AFAICT) no third-party firmware for common commercial routers seems to support this type of application, it does occur to me now that a similar effect to this can be achieved with two commercial routers. Put the guests on the router connected to the Internet, and connect a second, password protected router as a client on that router. Then the second router is a protected network, while guests have free access on the first. You'd lose some of the features such as the welcome page, but save some money.

I'd be interested in hearing from others at the address below.

Daniel Feenberg
feenberg isat nber dotte org

Note added November 2008

By the way, our host side MAC address was 00:0e:2e:ad:1d:4e and if you are searching through logs for signs of your unit, the first six digits are very likely to match those.