Slashdot Mirror
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?"
...might be that your router has to listen to every packet that comes in through the ethernet port that is connected to all those laptops, so you want a router where all packets are available to everyone (or at least to you).
Another part of the answer is probably that tcp/ip packets from these laptops have to have a return ip address, so WHATEVER the return address is, you'll be masquerading in the address of the server, and remembering who to send it back to. This is pretty much analogous to what happens already.
The DHCP part is easy. just have a dhcp server running, and it ought not to matter what it gives back.
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. :)
Al Qaeda has ninjas!
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.
Use a switch with VLAN tagging and one VLAN per port to connect to your router/host. Host will then substitute the real address if the user has static addressing or handle the DHCP request. Since each switch port is on a different VLAN you can use VLAN tags to determine whose machine sent you a packet. You can't do this at layer 3.
The Economics of Website Security
Try this here there was a space.
Who wants Pork Chops?
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.
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:
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
Assuming you have a bunch of ports on a switch going to a single ethernet interface, what you described may not be possible. Assuming you're doing this in a hotel, what happens if guests in two different rooms have their laptops configured with the same static IP address? There's no way to distinguish between the two guests.
And what happens when one guest has a hard-coded gateway that happens to be the IP address of another guest?
Excluding those two possibilities, you just set up a normal IP masquarade system with a DHCP server, and IP aliasing on the internal ethernet port. You set up the routing for the internal network to include all private addresses, which should catch people with static IP addresses. You then watch for ARP reqeusts and assume that they're looking for a gateway, so you add an IP alias for that IP address to the internal ethernet port.
That should coveralmost everyone. There could be someone with a static non-internal IP number if their laptop is normally on a real network, but you could catch that and add the necessary route, though that's dangerous if someone sets up a static IP of 64.28.67.150 to hijack slashdot, so I would recommend against it.
Oh, and just for kicks you might want to look into supporting PPPoE connections for anyone who is normally connected via DSL.
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.
11*43+456^2
Put it in Hotel-speak. What do you do when a customer asks for a non-smoking room so he can smoke? Don't forget that this is probably not supposed to be an *expensive* undertaking. Besides, as others have mentioned there are insoluble problems like IP reuse and discontiguous subnets. I presume here that you don't have explicit cooperation from the rest of that subnet to tunnel the laptop back through.
I'd start simple with DHCP and WINS. Then examine your customer base and see if adding a few static IPs makes sense without adding a lot of grief.
Trying to come out of the chute doing everything for everybody sounds like a surefire recipe for failure, with disaster an option.
The living have better things to do than to continue hating the dead.
watch for any packet coming in, or try and elicit a response by trying some common network requests (I'm thinking some kind of multicast "ping" but the correct term escapes me)
Anyway when you get a response you can try a reverse-ARP -- the machine *should* spit back its known IP. Of course you won't have any idea what the netmask or gateway is, but screwing around you may be able to determine this info.
It's an awful lot of non-standard work just to get this kind of bad bad system to work. You have to basically snat packets from the user, dnat packets to him and really really screw with the packets. It's not straightforward and it won't likely work well. Make them use DHCP or nothing. Or provide a network-terminal in the room for them to use. Honestly it's not a good situation any way you look at it if you won't accept them reconfiguring.
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".
11*43+456^2
First realize that what you ask is borderline impossible - You would have to handle
* IP's out of their subnet
** The LAN side of the NAT router would have to have a subnet mask of 0.0.0.0 to catch all possible client configurations
* Colliding IP's
* Guessing where to route packages based on port numbers alone (e.g. for local DNS servers and http proxy servers)
It can't be done at the IP level, you'd have to get below that level, and you'd have to keep all machines on separate VLANs (to avoid clients detecting IP address collisions). And the problems don't stop there, I bet.
THEN realize that especially laptops will very often be configured for DHCP.
In my opinion it would be much more interesting to accept that clients will need their computers to be configured for DHCP and ask: How can I offer wireless LAN support without risking abuse from neighbours, ensuring that people are charged etc.
First of all, your box will need to be kind of switch that is
directly connected via an ethernet cable to every client (without
any intervening hubs), that listens to every packet on the network
yet does not allow the different laptops in the room to communicate
with each other. Otherwise there are potential problems with someone
stealing Google's ip addres, someone sending bogus DHCP responses,
sniffing traffic, etc..
Your box is going to respond to every packet it receives, regardless
of the information in the packet header. Your box will ALWAYS act
as the default gateway for packets from clients, regardless of what
the received packet specifies as the next hop IP address.
* Whenever your box receives a DHCP query, it responds with a
DHCP response giving the address 10.0.0.1, and giving 10.0.0.2 as the
default gateway. The specific numbers don't matter...
* Whenever your box receives any non-DHCP packet, it uses NAT to
route it to the Internet, remembering the switch port on which
the packet came in in order to send the response to the right
place.
This can't work because you can't assume what the users will tell their OS what their gateway/router is.
What happens if you assign IP 168.1.2.32 to a machine and some moron tries to use 168.1.2.32 for their gateway?
Then there are the troubles of ip conflicts, etc.
Juse use DHCP.
The Mariott Hotel in Dallas (can't remember which one exactly) already does this. Your configuration matters not a bit. Just plug it in and go.
Give them a call and find out what they are running, and who provided the solution.
If tits were wings it'd be flying around.
Well, one way of doing it is assigning one network card per room - ie, you'll have one box with a dozen cards in it that handles a dozen rooms (you can get multiple ethernet cards - 8ports are not hard to come by). Have each concentrator box essentially act as a gateway on a per port basis. This is called "Killing gnats with a nuke." It works in every case, but is overkill. I'm sure you can figure everything else out with that basic description.
However, the most effective way to set this up is to assume that 80%-90% of your customers are coming in with a DHCP client. So you wire up the hotel as a regular switched network with DHCP. Then you get very cheap linux boxes, or reverse engineer some of those nifty broadband gateway devices and put your own code in. If a customer is having problems getting on then you truck up to the router closet and reattach their room to one of the linux boxes or gateways which acts like a dhcp enabled translator.
I suspect you can get a decent router to manage the physical connections and detect the situation so it is completely transparant to the users and the hotel staff.
Lastly, don't think of it in terms of IP addresses, think of it in terms of MAC addresses. Whenever you receive a packet inside the network with a new ip or mac in the packet, you add it to your database and instruct your NAT to route properly for it. The only situation in which you'll have a problem is when two people come in with the same static address. I'd suggest that this is such a remote possibility that you can instruct the hotel staph to physically reconnect a patch cable to another subnet on your network. Look into switches and routers that route by MAC address only. Then the subnets will take care of themselves, and since your box is dynamically applying IPs based on mac addresses you'll never have a problem.
-Adam
Some of the posters seem to assume the people in the hotel want to see each other on the network. That's probably the absolute *last* thing you want (if suits are expecting to move their laptop from the office to the hotel without any configuration, it probably means the laptop is wide open to hacks). What you want is a hardware set-up that makes each node think it's got a direct connection to the internet, not that it's on a LAN.
It should make the "what if somebody's configured with an IP address I've already assigned" easier-- if the nodes can't see each other you can translate IPs and not worry about conflicts. Assuming you can come up with a hardware configuration that allows that, of course...
How the hell are you going to get the person to change their default gateway? Its nearly impossible to get this, especially if you are on an internal network.
Two scenarios are unlikely to work out for you:
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.
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.
Vista:XPSP2::ME:98SE
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."Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
You'd need to reserve a proper routable address range and use that - no-one else should be using that; those with static assigned addresses will either be from their own routable range or one of the non-routables. Or they are configured very badly.
~~~~~ BigLig2? You mean there's another one of me?
All Marriott hotels are networked by STSN.
Lasers Controlled Games!
I can see that you would be able to accomplish this would be to have a gateway/router for every jack in every room. It would be just as easy to put a computer in every room (and I would rather that money be put in new bed sheets and mattereses :-)
So.. My suggestion is is to just show the staff how to setup DHCP. First, only support windows and Mac (version 9ish and up). Don't support Linux, BSD, Os/2 etc, because if they are using this, they will more than likely already know how to set it up.
Then, train the staff, seriously, It's not as hard as it seems, I've done it. In windows (and possibly mac, I've never used it much) make sure the hotel has all the cds they will need (or just put all the tcp/ip drivers on one CD). Show the staff how to install tcp/ip, turn on DCHP, turn on proxy if your using it, and then test it.
Walla, your done!
and a whole bunch of other stuff too. (E.g. client domain, WINS [yech], Samba node type, time servers etc.)
Go read some DHCP docs...
Er, yeah, I know that. What I meant (and maybe I didn't say it clearly) is that the *client* has to be configured to accept that information from DHCP.
That is, it's simple to configure a machine with a hard-coded DNS server, while still letting it get its IP address from DHCP.