Date: Fri, 05 Dec 2014 12:20:59 -0500 From: Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> To: "FreeBSD Questioner" <freebsd-questions@gmx.com> Cc: freebsd-questions@freebsd.org Subject: Re: Reserving localhost port numbers Message-ID: <44tx1adnd0.fsf@lowell-desk.lan> In-Reply-To: <trinity-84fc8143-9c27-4181-884a-0a20dea0af68-1417735030728@3capp-mailcom-lxa13> (FreeBSD Questioner's message of "Fri, 5 Dec 2014 00:17:11 %2B0100") References: <trinity-2843f6bc-834a-464e-a671-a16327e982ae-1417549546056@3capp-mailcom-lxa06> <44d281ajz0.fsf@be-well.ilk.org> <trinity-84fc8143-9c27-4181-884a-0a20dea0af68-1417735030728@3capp-mailcom-lxa13>
next in thread | previous in thread | raw e-mail | index | archive | help
"FreeBSD Questioner" <freebsd-questions@gmx.com> writes: >> Sent: Tuesday, December 02, 2014 at 12:13 PM >> From: "Lowell Gilbert" <freebsd-questions-local@be-well.ilk.org> > > Thank you for your reply Lowell! > >> > >> > When making these connections, the remote field systems "reverse >> > tunnel" certain listening ports to the server via the ssh -R >> > parameter. >> >> Ouch. That's pretty ugly, and (because you'll be running TCP over TCP) >> may not perform well. You might want to consider an architecture with an >> intermediary agent on the central server instead. > > Ugly may reside largely in the eye of the beholder 8-) > > We've been using this scheme for some time with very good > results. Although with a limited number of clients, and an ongoing > concern about port number collisions. > > The service ports on the remote systems are for relatively low > bandwidth communications. With our present number of systems, there > havn't really been any performance issues. If it's low bandwidth per-session (client), it won't be a problem. > By "intermediary agent" do you mean a dedicated service process on the central server? Yes. It doesn't need to be very sophisticated. On further thought, though, it doesn't really need to be a dedicated process; you can just have the clients make two connections, with one of them existing to let whatever you're running on the server send data back. On the *other* other hand, having the server make a separate connection back to the client would work better in some scenarios. And IPSEC should be strongly tempting, because port numbers become irrelevant. > One of the benefits of this scheme is that it requires no custom > service, or client, compiled software. Just a small shell script on > the clients. I can see the advantages of not needing a programmer. > We are considering scaling this solution though. So your concerns could still manefest with a larger number of clients. With a larger number of clients, you're going to have more port number collisions. As long as the client gets to choose its host-side port number, it's choosing in the dark. >> > It would be desirable to reserve a block of 10000 or so ports, anywhere above the 1024 "privileged port" range. >> > >> >> Are the sysctls in the net.inet.ip.portrange. set what you're looking for? >> > > Thank you for this sugestion! > > I have the standard portrange values: > > # sysctl net.inet.ip.portrange > net.inet.ip.portrange.randomtime: 45 > net.inet.ip.portrange.randomcps: 10 > net.inet.ip.portrange.randomized: 1 > net.inet.ip.portrange.reservedlow: 0 > net.inet.ip.portrange.reservedhigh: 1023 > net.inet.ip.portrange.hilast: 65535 > net.inet.ip.portrange.hifirst: 49152 > net.inet.ip.portrange.last: 65535 > net.inet.ip.portrange.first: 10000 > net.inet.ip.portrange.lowlast: 600 > net.inet.ip.portrange.lowfirst: 1023 > > I've been doing a bit of reading on these parameters, but I'm still not clear on exactly what they do. I'm a little rusty, so I checked the code. It's more complicated than it used to be, but my understanding still seems to be correct. > I understand that first and last control where the networking stack > will locate transient outbound connections, but there are still some > unknowns for me: > > 1) Say I increase first to 20000. Can i then safely assign my tunneled > ports into the 10000-20000 range? Or will the kernel consider it an > error for a user process to open a port outside of the first - last > range? You'll still be able to assign those ports. Keep in mind that other applications can also do so, although it's not something that happens much. > 2) What is the difference between the "default" range (10000-65535) > and the "high" range (49152-65535)? Which software will use which > range? An application can specifically request the high range if it wants. I don't think many do any more, but several FTP implementations used to. It was a firewall gimmick. > 3) Do these parameters only control where the kernel allocates ports, > or does the kernel use them as allowable ranges for applications > attempting to open ports? Aside from the reserved range, if you ask for a particular port, these parameters are irrelevant. Good luck.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44tx1adnd0.fsf>