barefoot   Frontpage - Barefoot - Download - Usage - Status - Support - Modules - Docs - Links - Survey - GDPR
 

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:

  • FTP

Copyright © 1998-2024 Inferno Nettverk A/S