Reserving localhost port numbers

[Lowell Gilbert]

"FreeBSD Questioner" <freebsd-questions at gmx.com> writes:

>> Sent: Tuesday, December 02, 2014 at 12:13 PM
>> From: "Lowell Gilbert" <freebsd-questions-local at 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.