[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Wed, 12 Jun 2013, Martijn Grooten wrote:
On Wed, Jun 12, 2013 at 8:21 PM, Mark Evans wrote:One issue with the "captive portal" idea is that it assumes traffic to port 80 TCP/IP. (With a web browser being operated by a human.) How would you treat traffic obviously not web browser related? e.g. VoIP and VPN.I might be wrong about some of the implementation details, but here's what seems to happen in most hotels (at least the bigger ones) these days: if an unknown device connects to the (open) network, any traffic from that device but TCP port 80 is dropped; TCP port 80 is sent to a local web interface. Once the user logs in on that interface, the device is recognised and future requests, regardless of protocol and port, are sent to the open Internet. I've used that in three different hotels in the past week. Once logged in, I was able to connect my laptop to the company's VPN without any issues.
That's more or less the system I implemented. Everything is firewalled - the connecting PC gets an IP address via DHCP, it's told what nameservers to use (the portal itself) then the firewall on the portal forces port 80 to it's own registration page - then when/if registered it adds that devices IP address into the firewall.
It works very well - I also force proxy port 80 web traffic too - that works better than it used to... Never perfect though, but when b/w is limited it was acceptible.
Some devices have issues - All Apple iDevices phone home to see if they are connected to the big bad internet so you can't implement a 2-state login process, it all has to be on the one page, else the iDevice thinks it's not connected and resets...
Gordon -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq