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.
http://www.ibiblio.org/pub/Linux/docs/HOWTO/mini/P roxy-ARP-Subnet is a link to the howto. Check it out.
But, isn't it possible by just looking at all packets coming in on the interface? Oh, but the gateway needs to be configured, client side. That's the kicker...the gateway could be anything, IINM. Or not...the gateway must be encoded somehow in the packets.
Hey, maybe I should read something about how TCP/IP works before posting. I'll leave this here as an anchor point for those who wish to respond to the article, that way it will be simpler for everyone. :)
Karma: Good (despite my invention of the Karma: sig)
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
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
Don't you love it when people say: I don't care how [Insert Your Favorite Standard Here] works, can't you make it work this way instead?
Long (read: expensive) answer:
Off the top of my head, I can't think of any COTS solutions to do what you need.
However, you could put some sort of NAT box with DHCP on every ethernet jack. Assign the "outside" jack of the NAT box to a static IP and NAT that again at a central place to get it out of the building.
Of course, just providing a computer in every room would be as simple.
There's so little difference between politics and jihad lately...
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
Here's something that might help
/sbin/ifconfig eth0 add 192.168.0.3 /sbin/ifconfig
[root@localhost network-scripts]#
[root@localhost network-scripts]#
eth0 Link encap:Ethernet HWaddr 00:03:47:6D:8B:3D
inet addr:192.168.4.8 Bcast:192.168.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:95 errors:0 dropped:0 overruns:0 frame:0
TX packets:158 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:11 Base address:0x8000
eth0:0 Link encap:Ethernet HWaddr 00:03:47:6D:8B:3D
inet addr:192.168.0.3 Bcast:192.168.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:11 Base address:0x8000
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.
Here is a company that provides the service to hotels that does what you want. Have no idea what is under the hood though:
: globaloop.i.pl/pdf/globaloop-ghotel.pdf+%22no+reco nfiguration+required%22&hl=en
http://globaloop.i.pl/pdf/globaloop-ghotel.pdf
Here is the google html of the PDF, as the server is SLOOOOW:
http://216.239.35.100/search?q=cache:ylDnHL43FNIC
http://www.viatornetworks.com/base_pages/server_in stall.htm
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
the problem is that in order for your firewall/router to be able to route dhcp from any arbitrary ip address, it has to bind all ip addresses. this would be problematic if a laptop wants to have that address, or if you want to assign that address using dhcp. of course, you could just bind the popular "server" addresses for the popular internal network addresses, so that 95% of people do not have to reconfigure their laptops. (see another post which provides a clue how to do this)
;-P
eg. you don't have to bind 0.0.0.0/0, since you could bind 192.168.0.0/16, 10.0.0.0/8, etc. separately.
Laptops with really strange(tm) configurations can be told to use dhcp with any one of a dozen server addresses, or else given static addresses. As long as you don't promise that your network will work with 100% of all configurations, you can probably make these hotel contracts work.
As a start, try playing around with ifconfig in your internal linux network to see what tricks you need depending on the ip address your internal computers are trying to use.
also, depending on how many client ports are needed, make sure to not put them all on the same router & firewall ethernet card. the more clients are on the same network, the higher the likelihood that they will have ip address collisions. This is especially true of the 192.168.0.x range, since it is very very common. The bright side is that since these are laptops, most or all of them should be using dhcp anyway, so the whole (you don't have to reconfigure) feature would basically boil down to having your firewall bind to the common server addresses, and set up dhcp servers bound to each address, allocating different ip address ranges.
probably easier to say than to do though...
Good luck.
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.
You can do quite a bit, a ton in fact on a single port protocols. However, you screwing with IP addresses which might screw up IP/VPN/Security/Authentication mechanisms all over the place causing people more problems then just explaining they have to configure the network properly. The real problem is all of the solutions are executing a man in the middle attack. In this case, it is a useful "attack", but an attack none the less. A good security protocol might pick up on it and stop working.
If you just want them to be able to surf the web, yeah no problem. To reliable be able to accomplish useful work using any tools they are use to, nope too many configuration and or problems with it. Kirby
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...
Dont try and build it yourself, there are a ton of headaches, ones you don't realize until you actually start implementing and it doesn't quite work.
http://www.solutioninc.com/
I am not affiliated with the company but I know a few of the people working there that developed it (and saw how they were pulling their hair out at times). I have stayed in a few hotels using their product and it just worked.
After you have solved the problem with ip-addresses, network masks, etc, you might also consider handling bandwidth hogs. Some PHB is bound to download as much as he can. Maybe you can use traffic shaping to limit each single PCs bandwidth to a certain ratio of the upstream bandwidth (depending on the number active PCs).
The hotel might also want to bill per megabyte download or per day. I seem to recall that you can get statistics out of ipchains.
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.
Try looking ad nauseam. Maybe you'll succeed then.
Don't use latin phrases if you can't spell them.
A simple solution would be to have the person staying in the room give the front desk their IP and they could just punch it in for him. If its already taken they could issue him another one, and unless you're a retard its not that hard to reset it on your lappy.
"you sonofabitch i didn't know!"
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
Very good idea.
I fail to see the necessity of such a bastardized network. If one of the hotel occupants needs his internet connection badly enough to pay the hotel 20$ for one night, then I'll assume he already knows how to use DHCP. If not, then someone in the hotel will be available to set up his laptop accordingly for another 20$. If they're doing something that requires broadband access, then it's safe to assume they're doing something fairly technical and/or important that justifies the expense or at least basic training on how to configure the network connection. If they're a CEO checking their email in-between suit conventions, let them dial up through a phone line and wait a few more milliseconds.
-Billco, Fnarg.com
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
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...
In short, I would try to explain that for reasons of security, simplicity and budget there is no reasonable solution at the moment. That's what I would do, at least
You are an optimist. You assume:
-People know the difference between a NIC and a modem jack.
-laptops always run on different voltages. (110-240 Volt). we are talking hotels.
-Those company laptops: "The administator has restricted access to the network". (So users are not figgling with their settings).
-You made a dhcp+nat setup. You made A4 papers explaing how to set up dhcp (and remove proxy settings). You forgot to make a japaneese sheet. Japaneese people own the hotel chain.
Do not forget that as soon as the hotel guest gets back to work and there are *any* problems, they will likely blame the hotel techie for screwing up their laptop. "it used to work" etc.
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?
So lets say I don't even have TCP/IP installed on my laptop, then what?
What if internally they use some other protocol to get to the internet? With some translations you can use say IPX for example to connect to the internet. I'm sure such a case would be rare, but you never know what you might run into.
Nomadix makes the USG, a network box that was designed just for hotel internet access. It solves the problem of computers with static IP addresses, and also includes hotel-oriented features like billing.
All Marriott hotels are networked by STSN.
Lasers Controlled Games!
The ISC DHCP server will ping an IP address before it assigns a lease. This should work well for almost all clients except Win95. Win95 will reply back even if it doesn't have a lease eventually stealing all of your IP's. As far as supporting public IP's and private IP's two gateways should handle that fine.
Educate the Hotel People.
Explain to them what they want.
Explain to the the extra time/money/effort required.
Provide an alternate solution, or charge them out the wazoo =)
Enjoy =)
"Just Smile and Nod." --Huck
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!