An Example SOCKS Configuration Guide

Begin by choosing your Internal and External interfaces. This must be properly configured for the SOCKS proxy to work correctly. Click the Save Settings button to update the configuration.

Rules are evaluated in a top-down manner. In other words, when a connection is requested the SOCKS server will walk through all the Access Control Lists (ACL's) (in a top-down fashion) and allow/deny the connection as soon as it hits a matching rule.

A sensible configuration is to have a block rule at the bottom of the evaluation chain so that access is denied if there is not a rule explicitly allowing it. Enter pass rules for subnets above this. Finally, you would add block rules above these for specific clients or ports to be blocked.

The following configuration uses CIDR notation to represent the networks. For a explanation of what CIDR notation is refer to page .

Consider the following setup. 1.2.3.0/24 is our local subnet (the one we want to grant access to), and 1.2.3.200/32 is a specific host we wish to block:

Action	From	To	Port
block	1.2.3.200/32	Any	Any
pass	1.2.3.0/24	Any	Any
block	Any	Any	Any

When a connection is established the SOCKS daemon will look at the first ACL. If the client making the request is 1.2.3.200 then access will be denied. If it is not then the SOCKS daemon will move to the next rule. If the client is on the subnet 1.2.3.0/24 then access is granted. Finally access is denied if the client making the request does not match any other rules.

Important note! As stated above there are two types of access control rules: Client Rules and SOCKS Rules. The example above applies to both rule types; they are logically the same except for the point of the connection where the access control mechanism is used.

This WebTool module is designed to provide the capability for a very broad Client rule allowing everybody on your LAN and very specific SOCKS rules blocking abusers/sites/ports.

The following is a slightly more advanced configuration.