Configuring a (User-Side) Hassle-Free Network?

braek asks: "I have been approached by a few locations (Hotels/Convention centers) in regards to providing high speed Internet to clients. Now, I'm sure this has been done a million and one times with a small x86 box running some flavor of Unix or BSD, however the thing that makes this somewhat of a more difficult chore, is the fact that the hotels and convention centers want absolutely NO reconfiguration to be required on the users laptops. So for example, the router must be able to route packets for people who have DHCP, as well as someone who has a static reserved IP address of 192.168.4.8 and someone who has a static global of 206.10.3.9. Basically the router should be able to route packets for the user regardless of their IP configuration. I Have looked around the web ad-nauseum but have found very little help. I'm thinking some form of transparent bridge or proxy-arp solution may be the key. Has anyone ever been in a situation like this, or have any ideas as to how this could be accomplished?"

Comments

Not too hard

[photon317]

First off, for security this gateway box should be running OpenBSD. Nothing else can compete when it comes to being a secure firewall that's open source, flexible, and feature-rich. That aside...

Run a stateful packet filter and NAT, do all the standard stuff so that they can get out via HTTP, mail protocols, FTP, and VPN (i.e. Cisco vpn cleints).

Run a DHCP service for the (hopefully majority of) users that either use DHCP anyways, or have the smarts to set their network control panel in winbloze to "autodetect" when they plug into the hotel.

It's the handling of the wierdos that is problematic. One can assume that the worst case you're willing to support is a guy with a static network configuration of a certain IP, gateway, netmask, and nameservers, all of which don't from the hotel (they are from some company's intranet).

First off, get a real subnet for the internal NATted DHCP, so that hopefully nobody but you will have used it (i.e. if you used 192.168.x.x, a lot of static config laptops might just happen to use it too, and it would be hard to tell them from your well-behaved DHCP clients).

Have a sniff on the inside network logging all packets whose source address doesn't match your assigned network. Dynamically insert a rule into your PF and your routing table to make things work for any IP you see on the wire (i.e. you see a source packet from 1.2.3.4, you add into your PF/NAT/Routing setup rules/routes/etc that allow that IP to work). The real trick here is avoiding the problem of someone's laptop having www.yahoo.com's IP address. You might ahve to play some funny rule or policy/tagging trickery to make sure that these added routes don't apply to outbound traffic from other clients.

Proxy arp for EVERYTHING but your internal assigned client IPs on your internal interface, this should take care of their random default gateway setting. Grab all DNS requests (port 53) and silently redirect them to the local DNS service regardless of where they were supposed to go.

etc... etc...

I'd have to actually set up a test environment and do this once to find all the flaws and fix them, but you should be able to go down that general path and make it work.

public port

[OpenMind(tm)]

At the Univeristy of Illinois, we have a system that does much of what you're looking for, although a foolproof solution is probably not on the market. The network hardware, from Public Port, would tolerate quite a few unreasonable network configurations. You could, for instance, forget that your laptop was statically configed to an IP on one of the campus public networks, and the system wouldn't miss a beat. I've noticed most NAT systems are pretty tolerant of this sort of thing, but this system is seemingly engineered for it. I believe the hardware is currently known as the Tut Systems Expresso SMS/OCS.

Two scenarios are unlikely to work out for you:

1. Two users on the private network with the same staticly coded IP. With the proliferation of home NAT routers, this is not unlikely.
   
2. A user on the private network tries to contact a public IP address claimed by a machine on the private network. This is fairly unlikely.
   

To get around these possibilities would require each port to be treated like its own NAT domain, as well as some fancy routing logic. I won't say it is impossible, just very complicated.

Get 'em on DHCP

[raju1kabir]

I'd suggest doing it this way:

1) Run a DHCP server to handle the normal people.

2) Slurp up all traffic originating from an address not handed out by your DHCP server. Respond to requests on viable protocols (telnet, http) with a notice informing people how to switch to DHCP.

3) Put cards by the telephones that explain how people can set their machines to use DHCP.

4) Provide raju1kabir with free rooms chainwide for life in exchange for this helpful advice.

You could easily just alter step 2 in such a way that you indefinitely NAT people's traffic regardless of their preconfigured static addresses, but there is some chance that you'll have two guests who are both set to 192.168.1.1 or who have their gateways set to each other's addresses or something. The chance is slight, but it's hard to deal with without expensive physical segmentation of the network. So it's best to minimize the chances by getting 'em to switch to properly allocated addresses ASAP.