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

Pray tell . . .

[cjpez]

. . . what range of IPs would you assign when doing DHCP for someone, then? Someone's configuration is going to give you problems. If you assign someone a DHCP address in the 10.x.x.x block and then someone comes in with a static 10.x.x.x for some reason, you're screwed . . . I suppose in that scenario you could tell the DHCP server to not use that one IP address. But then what happens if the DHCP server assigns somone 10.0.10.10 and then someone comes in with that static IP? You've got a mess on your hands, that's what.

Not to mention if someone comes in with a laptop that has a publicly-accessible IP; it's possible, anyway. How will you know to route that properly? I suppose that's pretty farfetched, actually, because the person with a publicly-available static IP on a laptop wouldn't expect it to work outside the network it usually sits in. But still, if that's one of your requirements, what then? Where does traffic to that IP route? Out to the world the way it's supposed to, or inside your hotel network? If you allow global IPs and do some funky route hacking, it would be trivial for someone to boot up their laptop with an IP of 216.239.39.101 and suddenly nobody in the hotel can get to Google. Bad idea.

Someone's toes are going to have to be stepped on somewhere along the line. Someone else can come around and prove me wrong, though, if they can. :)

Tough Part.

[MindStalker]

There are two tough parts to this, one, people may have identical ip addresses, and would upset eachother, two computers trying to reference ip addresses that exist out on the internet could accidently hit other computers on the network if they are ipd wrong. So the only way I could see this working, is to have a small device on each ethernet port that on the network side, has a preconfigured ip address assigned by the hotel. And on the laptop side, reads whatever ip address the laptop that gets plugged into it has, and just accepts it, and then just translates one to the other. I don't know if this device exist, but if its a large enough hotel chain, I bet they could find a company willing to make it, should be simple enough of a device.

Cant Be Done

[linuxbert]

It Cant Be done. dhcp is easy, but there is now way to route an ip packet to a laptop that is not part of an contiguous network, ie the 205.211.44.xxx subnet exists in ottawa, but my laptop which is a member of that subnet is currently in washington, is not gonna be able to have packets routed to it.

i suppose it could be done if you wrote a gateway that useses a netbios like layer 2 protocol (using mac addresses) and proxying requests and responces from layer 3 (ip) to layer 2 (MAC)
Hope that makes sence.

Interesting. Might be "sorta" doable

[dschuetz]

This is an interesting problem. At first blush, it seems that it should be possible. Consider a web request at a packet level:

• the laptop spits out a packet for, say, 10.3.5.1, and it contains a DNS request for www.slashdot.org
  
• some network device configured to receive all packets snarfs that up
  
• The device looks at the packet, sees it's a DNS lookup, does the lookup, and then spits out a response packet
  
• the laptop now sends out an HTTP packet for 64.28.67.150
  
• the magic box sees that packet, recognizes it for what it is, and forwards/NATs it on to /.
  
• ... etc ...

So far, so good.

Of course, if your laptop sends out a DHCP request, then all the pertinent information (router, DNS, etc.) can be returned that way -- but then again, the laptop has to be configured to accept, for example, the DNS server via DHCP and not be hard-coded.

So, yes, sure, conceptually it might be possible. And it might even be "easy" to implement. But I can think of a few problems, offhand:

• First, what I described above -- where some data (IP and subnet, for example) come via DHCP, but router and DNS are hard-coded. The system will have to be able to work in both "transparent magic box mode" and "sensible DHCP mode" at the same time, for the same client.
  
• Cases where the laptop's "home network" is comprised of routable addresses, and they want to access something on that network. Er, wait, this might actually work -- but the system would have to keep track of "internal" IP addresses (used by the guests' laptops), so that if, say, two folks from the same company want to file share between their laptops, the system won't forward those packets onto the internet, but'll just let them sit there on the local net.
  
• ...I can't think of any other issues right now. I'm sure there are plenty.
  

As I said, interesting idea, and I'm really curious if it actually is possible, or if I'm missing something significant here.

If you implement a cool solution, document it somewhere on the web and send it back to /. again!

Another option

[photon317]

The consensus (probably correct) is that it's going to be quite difficult to implement, and it will always have corner cases which cause problems and maintenance nightmares, or worse hijacking of public sites.

So here's a semi-manual different approach:

Setup the yadda yadda yadda firewall+nat+dhcp standard setup, assuming that all clients are set for dhcp.

Build a "laptop checker" box with a port hanging out at the reception desk. Inform clients that if they use DHCP (autodetect) like most companies do, they will be fine. If they have doubts or don't know, you can test their laptop's network compatibility for them.

They plug into the network jack, either a green, yellow or red light lights up near the jack (linux can easily control LEDs :)

Green means the test machine got a DHCP request from the laptop, so it should be ok.

Yellow means no DHCP request, and we saw traffic sourced from some random IP. The IP was pinged for on the outside internet, and found to be non-responsive (unlikely hijacking), and doesn't seem wierd in any other way (multicast IP, or the IP of one of your routers, or the IP of another Yellow Light customer currently checked in, or anything else goofy). The receptionist can then (from some little gui) tell the network tester to allow them access. This turns on a special route for them on the inside, and sets it to be removed when they check out. They are warned that if they got the yellow light, we can't support any technical problems they may experience.

A Red light means there was no DHCP response, and either we didnt see any traffic at all to look at, or they have some bad IP we dont want to assign. We dont add any routes, and we tell them it won't work.

In both yellow and red conditions, you probably want a little handout to give them that walks through the basics of making your laptop autoconfig so it will work "properly".

Re:Switch w/VLAN tagging to Host

[regen]

In my haste to reply quickly, I left out details that I thought would be clearly seen once I said use a switch with vlan tagging.

The upload to the host/router is via trunk port on the switch which is a member of all vlans. Since it is a trunk port the switch will forward the frame which the 802.1q tags on the frames.

The host/router is configured with virtual interfaces on each vlan. Since the tags are present it can determine which packets belong to which ports on the switch.

The host/router will use NAT/PAT to map the entire 0/0 address space to a single IP. Thus it will not matter what address is statically assigned to the laptop.

Since the ARP request will be confined to the VLAN only the host/router will see them and can respond with it's MAC address, thus it will become the gateway router for that port. Likewise you can map services that you would like to provide locally such as DNS this way (or just let DNS pass)

Of course, if they send a DHCP request you don't need to do all this work.

You should be able to do this with of the shelf components. A Cisco 3700 series router could handle a small setup and a Cisco Catalyst 5500/6500 with RSM could handle much larger setups. Any CCIE with much VLAN experience should be able to set this up.

If you want to go Open Source, you could use a Catalyst 5500/6500 with an OpenBSD/Linux/FreeBSD box instead of the RSM. You could even throw a bunch of quad nic into a box instead of using a switch but that would be a mess to manage.

Varying responses

[NaDrew]

I'm not even close to being knowledgeable enough on networking to provide a useable response. I just thought it was funny reading the replies and seeing how they alternated just about one-for-one with "can't be done" and "should be easy, here's how".

Do the people who think it "can't be done" need more knowledge, or are the ones who say "should be easy, here's how" missing a vital point? Or maybe both?

Fascinating reading either way.