Configuration of SocksProxy

Connection Types:

The basic scenario is a machine, A, that wants to connect to another machine, B:

A => B

Note that here and in the following, A and B and the other players can be referred to as "machines", but any combination of them, even possibly all of them, can easily be located on the same machine, and should really be considered "applications" instead. However, thinking of them as machines will sometimes make it easier to hold an overview of what is actually going on. Typically though, the network on the immediate right side of the (first) proxy is the internet, while other networks involved are typically local, at least for the tunnel examples – but it is not necessarily so.

If A for some reason cannot contact B directly, it can use the help of a proxy that can:

A => P => B

A proxy can be transparent, in which case A isn’t even aware that a proxy is in use, except perhaps through the use of a different ip address and port, but the protocol in the communication at least isn’t aware. A proxy can also be a socks proxy using either socks 4 or socks 5, in which case A must first negotiate with P to establish a connection to B. This is the basic difference between transparent and socks proxies; the proxy needs to know how to contact B, and for a transparent proxy, it must be configured in advance, for a socks proxy, A is required to deliver this information, including any user name and password necessary to access the socks proxy. This requires a more complicated application A, but then the same proxy can be used for different B’s, whereas a transparent proxy can only contact the preconfigured B.

Proxies can be chained, meaning there is a chain of any number of proxies between A and B:

A => P => P => B

For transparent proxies, this is the precise description, but for socks proxies, the situation is more complicated. If the second proxy in the figure above is a socks proxy, then the first proxy will need to know how to communicate with a socks proxy, including socks version and any user name and password - just as A needs to be able to do this in case the first proxy is a socks proxy. The SocksProxy application is doing this through the concept of a "carrier":

A => PC => P => B

The second proxy is considered a "carrier" of the communication from the first proxy to B, so the first proxy must have a carrier interface that can take on the task to communicate with the second proxy, the carrier, on behalf of the first proxy. For a transparent second proxy, no carrier interface is of course required, for any other type of proxy, a properly configured carrier definition must be used. In the following, the word "carrier" is used to refer to the carrier definition belonging to the first proxy, while the physical carrier is refered to simply as the "second proxy".

SocksProxy also offers the use of tunnels, having the benefits of taking some of the danger out of exposing the second proxy to the internet. A tunnel is using a proprietary protocol, it can be encrypted, and it is possible to change SocksProxy to only accept certain ip addresses.

A special kind of tunnel offered is the "reverse tunnel":
A => PC <= P => B
Note that the communication line between the two proxies is created in the opposite direction. This can be useful in cases where firewalls or NAT routers are involved, or if a static ip is not available on the second proxy where it is needed, but is available only on the first proxy.

SocksSetup:

SocksSetup can administer the setup of both (user) local and service settings, local settings are used when running the proxy with the -l option. In the SocksSetup application, you will find 3 tabs called "Proxies", "Carriers" and "Names". The "Names" tab can be used to define aliases for ip addresses that can be used just as dns names. This will sometimes make it easier to create and maintain the proxy and carrier definitions, but it is also possible to use the ip adresses or dns names directly, the use of defined names is optional. In the examples below, no names but only ip addresses are used for simplicity.

Examples:

In the following are shown examples on how to set up the scenarios mentioned above:

1. To create a transparent connection, A => P => B, a transparent proxy must be set up:
   
   Note that port 80 is chosen arbitrarily. It could as well have been any other port, even different ports depending on the services involved. A "GRE Proxy" is used for a Microsoft VPN. Note that no carrier is chosen, since the proxy has direct access to B – or it has access through another transparent proxy, in which case it doesn’t need to know.
2. To create a connection through a socks 5 proxy server, A => P => B, a socks 5 proxy must be set up:
   
   Note that no specification of the destination, B, is present, A will supply this during the initial negotiation. Note also that the public ip address, which is required for socks binding, is not explicitly known here, but will be determined through querying an external service. No authentication is specified in this example.
To create a connection through first a transparent proxy, and then a socks proxy, A => PC => P => B, the two different proxies should be configured like this:

Note how this proxy is defined in the same way as the proxy in example 1 except for the use of the carrier, which must be defined as follows:

The "Carrier IP Address" is the ip address of the actual carrier, the second proxy. The second proxy can then be defined on the machine running the second proxy as follows:

Note that the carrier definition’s "Carrier IP Address" and port must match the second proxy’s "Listening IP Address" and port – although "All Adapters" or a dns name would of course also be acceptable for the second proxy. Note also that the final destination, B, is configured in the first proxy.
4. A tunnel is a special kind of proxy. Once the connection is made, it can carry many connections from different A’s to as many B’s. A tunnel is by definition chained, since it requires a first proxy using a carrier definition and a second proxy. This is an example of the first proxy:
   
   Note that the first proxy is transparent, so A will never know anything. It is however using a carrier to reach the destination:
   
   Of course, the second proxy that this carrier definition is to match, looks like this:
   
5. If for some reason it is not possible to configure a carrier to reach the second proxy, either because a firewall or a NAT router prevents it, or if the second proxy doesn’t have a static ip address that can be configured, a reverse tunnel can be used instead:
   
   This proxy looks exactly like the first proxy in previous example, except for the choice of a different carrier, which is defined like this:
   
   Note that this carrier also includes a "Listen IP Address". This is due to the nature of the reverse tunnel. It is not the carrier that connects to the second proxy, it is the second proxy that connects to the carrier. The second proxy looks like this:
   
   Note that this proxy does not have a listening address, but rather a "Destination IP Address" and port, which match exactly the carrier definition. This way, the second proxy can connect to the carrier definition with the first proxy, and then any connection going through the first proxy can be routed through the tunnel to the second proxy and on from there. A reverse tunnel proxy is of course not capable of knowing exactly when the first proxy will need its services, so for reverse tunnels, the connection is set up permanently – and reconnected as soon as possible, if it breaks. To know if the connection is still valid, when not in use, a heartbeat is sent every 4-5 minuttes, so unless a connection becomes impossible for other reasons it should never take more than 4-5 minutes to detect a connection failure and reestablish it. If the connection is closed gracefully for some reason, the second proxy will immediately try to reconnect, and continue to do so with gradually longer intervals.

Configuration Parameters In Detail

The structure of the registry keys under the SocksProxy key is as follows:

Proxies\<name>\

    Active (DWORD)

    Authentication (SZ)

    Carrier (SZ)

    ChaChaKey (BINARY)

    Compression (SZ)

    DestinationIP (SZ)

    DestinationPort (DWORD)

    Encryption (SZ)

    ExternalIP (SZ)

    Gre (DWORD)

    InternalIP (SZ)

    ListenIP (SZ)

    ListenPort (DWORD)

    PublicIP (SZ)

    Protocol (SZ)

    ResolveRemotely (DWORD)

Carriers\<name>\

    Authentication (SZ)

    ChaChaKey (BINARY)

    Compression (SZ)

    Encryption (SZ)

    ExternalIP (SZ)

    IP (SZ)

    ListenIP (SZ)

    ListenPort (DWORD)

    Password (SZ)

    Port (DWORD)

    Protocol (SZ)

    Username (SZ)

Names\

    <name> (SZ)

Even More Detailed explanation of the configuration.

Proxies

When configuring a proxy, first consider what type of proxy you need:

Protocol (SZ)

    "Transparent"

    "Socks"

    "Socks4"

    "Socks5"

    "Tunnel"

    "ReverseTunnel"

Next, specify the ip and port to listen on. These are the values that you will need to put into your client application. Note that for a reverse tunnel proxy, no ListenIP and -Port are required, rather DestinationIP and -Port as the proxy is to make a connection, not receive one.

ListenIP (SZ)

ListenPort (DWORD)

If your proxy is on a multihomed PC (it usually is), you may configure the ip address to connect from, to ensure that the connection is established on the right network adapter. This address is only used by a reverse tunnel proxy, while a carrier has its own external ip address.

ExternalIP (SZ)

A reverse tunnel proxy will need to connect to the carrier, so just like you configure an external ip address to connect to the requested server from, you can also configure the internal ip address to connect to the carrier from.

InternalIP (SZ)

When using one of the Socks protocols, the required type of authentication must be specified:

Authentication (SZ)

    "None"

    "UsernamePassword"

Certain elements of the Socks protocol requires the socks proxy to know on which ip address servers will connect to when doing callback. When chaining to another proxy, this is not relevant, but when not chaining, (the most frequent case), that ip can be specified as:

PublicIP (SZ)

If you are configuring a transparent proxy, there are a few more choices to make. For transparent proxies, the client application should be configured with the proxy IP address and port, and the proxy should be configured with the actual destination IP and port. The DestinationIP and -Port are also required by a reverse tunnel proxy and should specify the ip and port of the client's carrier.

DestinationIP (SZ)

DestinationPort (DWORD)

If you are using the transparent proxy to route a Microsoft VPN, you will need to route the GRE protocol as well:

Gre (DWORD)

    0

    1

When configuring tunnels and reverse tunnels, you also have the choice of using compression and encryption.

Compression (SZ)

    "None"

    "Runlength"

    "Huffman"

Encryption (SZ)

    "None"

    "ChaCha"

Note that already compressed and/or encrypted streams cannot benefit from further compression, where encryption always adds another layer of security. ChaCha encryption does not offer forward secrecy though, if the shared key is compromised.

Sometimes the proxy server cannot itself connect directly to the desired destination, but will need to connect to another proxy server, possibly even of another brand. This is possible, (except for the transparent protocol) if that other proxy server implements the Socks protocol in a similar manner with respect to authentication. Specify that other server as a carrier:

Carrier (SZ)

IP Addresses and Names

"0.0.0.0"

"0.0.0.1"

Carriers

Protocol (SZ)

IP (SZ)

Port (DWORD)

ExternalIP (SZ)

Authentication (SZ)

Username (SZ)

Password (SZ)

Compression (SZ)

Encryption (SZ)

ChaChaKey (BINARY)

ListenIP (SZ)

ListenPort (DWORD)

Examine the log from the proxy server when it is started, to see if all the requested proxies have been correctly started.

Home

Last revised: 2019-05-15
·