Port redirectable clients
This page covers the Barefoot port bouncer client
compatibility.
Barefoot supports TCP and UDP. Other protocols (e.g., ICMP, SCTP)
are not supported.
No special client configuration is necessary for use with the Barefoot
port bouncer, but there are some limitations on the application protocols
that can be used with a port bouncer, and some practical consequences
resulting from port bouncing that it is useful to be aware of.
Semantic differences
One practical difference between a communication path that uses a
TCP/UDP level port bouncer and one that is as normal routed directly
between a client and a server is that there are two sessions instead of
one. There are two TCP connections and two sets of UDP endpoints. For
UDP, the port bouncer essentially becomes just one more hop, but for
TCP there are situations in which having two connections can give
slightly different semantics.
For TCP, a connection is first established between the client and
Barefoot. Barefoot then attempts to establish a connection between
itself and the target server. When Barefoot successfully establishes
the connection to the server, the behavior observed by the client is
essentially identical to that of a direct connection.
It is however possible that the connection attempt made by Barefoot
will fail, for example because the target server was not running.
This will result in a connection refused/ECONNREFUSED error
when Barefoot attempts to establish the connection to the target server.
At this point the client has however already established a successful
connection to the Barefoot port bouncer, which as far as the client
is concerned, is the target server.
When this happens, Barefoot will of course signal then client that
an error has occurred and close the session, but this error will not
be the same as the client would have received if the client connected
directly to the target server.
- Direct connection: ECONNREFUSED connect() error
- Redirected connection: Possibly ECONNRESET during I/O
In practice, this should not matter in most cases because both errors can
occur during normal application usage.
Protocols that specify IP-addresses for use
Clients connect to the Barefoot port bouncer, which will have a
different address from the target servers that traffic is forwarded
to. If one of the target servers inserts it's own address somewhere in
the protocol exchange between itself and the client, this address
will typically be an address that the client cannot reach.
An example of this is if passive FTP is used, wherein an FTP server will
provide the FTP client with an address and port number that the
ftp client should connect to. The address provided will however
be that of the FTP server, and not one of Barefoot's addresses.
Active FTP has the same problem, though in this case it it's the FTP
server that will attempt to connect to the FTP client.
Barefoot is a traffic relayer and will not rewrite data
transmitted through it, meaning protocols (e.g., the FTP protocol)
that specify IP-addresses to use for secondary connections between
clients and target servers will not work.
Compatible protocols
The following is a non-exhaustive list of some popular protocols that
can generally be used with the Barefoot port bouncer.
- HTTP/HTTPS
- DNS
- SSH (care should be taken with keys)
- SMTP
- POP
- IMAP
- ...
Less suited protocols
These protocols are either not usable, or not easily usable:
|