Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm a programmer trying to figure out some stuff beyond my domain:

Say I have one machine and clients will make tcp (but not http!) connections to it. I want to redirect clients to their own ports based on which hostname they connect to. For example, client1 connects to and is connected to port 1234. -> 1235, -> 1236, etc.

I want to dynamically control how ports x, for host y actually point to port z on my physical machine.

While googling this info, I see references to firewalls, proxies, reverse proxies. Which software do I actually need? Does existing software allow such changes on demand (I have heard have firewall changes requiring a day)?

If I wanted to write such a layer myself (since it may be a bit application specific), could it be done in java or node.js (I mean could it be done using higher level API or do I have to start taking apart ip packets)? How would I know which hostname the client connected to, since all host names resolve to the same machine?

I'll appreciate pointers to any reading material as well.

share|improve this question

At the IP level, there is no such thing as a hostname. A hostname is an application-level abstraction of an IP address, and at the Internet or Transport layers they hold no meaning.

In HTTP shared hosting, this trick is abstracted in the process of handling the HTTP conversation, which happens after the TCP conversation is started. It is for this reason that running an SSL server required a dedicated IP address for so long, as the SSL conversation takes place before the HTTP one (this has since been fixed in newer TLS releases where HOSTNAME can now included as part of the SSL negotiation).

For a shared-hosting HTTP instance the protocols are negotiated in roughly this order:


Each protocol can not be started until the earlier ones are completed. Until recently, only the last step in the chain was aware of hostnames, which is why it was up to the webserver software to handle a many-to-one association of hostnames to IP.

For a dynamic port forward, this is only doable if the application protocol is somehow aware of hostnames. Some device (be it software or hardware) handles the initial TCP connection with clients and the first steps of the application protocol (whatever that is) and forwards the connection on to its ultimate destination based on what it received.

The exact steps needed vary based on the application protocol itself. Some, like HTTP, include a HOSTNAME header indicating the hostname the client expects to be talking to. Others, like some Microsoft protocols, leverage DNS-based SRV records to determine a precise IP and port combination. Since it sounds like you may be designing your own application protocol from the bolts out, I'd suggest following HTTP's lead and include a HOSTNAME header in your initial protocol negotiation steps.

share|improve this answer

Can you describe in clearer terms what you're trying to do and why? The "Why" will help greatly. What are the clients? What is the protocol?

There are many ways to do this based on the protocols and data streams.

Consider pf, iptables or ebtables injection, see "ssh blacklist" for examples. Look at LVS, HAproxy and other load balancers for general redirection.

An old trick is a "wake-up" system. This works great for SSH or other encrypted protocols that make it more cpu intensive to determine source domain.(decode the header) This leaves only a single port running when no one is connected.

  • SSH in to a single open port (no terminal support necessary)
  • log into system as userX (preferably using keys), this runs a script that starts up another instance of the server on port XXXXX and replies to the client with the new port number
  • "port XXXXX is open" message is transferred back to client, initial ssh session is closed
  • client or client app then re-connects using the now open port XXXXX
  • when client disconnects the alternate instance on port XXXXX is closed and/or port XXXXX is closed.

Specific ports can be assigned based on keys/users, reverse lookup, message passing, etc. Some just leave the instances running and open/close using pf/iptables firewall injection. Others extend this using a firewall rule to trigger the service startup and have no initial SSH (or other service) running until a specified port is pinged with a specific type of packet. I prefer a "recently matched" custom firewall rule to block stray packets and stopping/starting the server instances for less dynamic interaction with the firewall.

This idea can work with any protocol and service that can be coded or scripted.

Reading materials for TCP/IP Networking: Anything written or recommended by W. Richard Stevens.

Don't discount using SSH tunnels as a in-development stopgap. These could achieve everything you need with no code. What is your app? Shouldn't it's communication be secure? How are you going to blacklist script kiddie hackers? That's more you'll have to write and debug. You should be compartmentalizing your code anyway, so develop everything else using SSH as the transport, port forwarding, encryption, usage logging, blacklisting, etc.. Then when everything else is done write your own network protocol mechanism to replace SSH. There is no need for terminal access for users on the gateway SSH server to use tunnels.

share|improve this answer

You can achieve this most easily using SRV records in your DNS:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.