# This is the configuration for libtsocks (transparent socks)
# Lines beginning with # and blank lines are ignored
#
# The basic idea is to specify:
#	- Local subnets - Networks that can be accessed directly without
#			  assistance from a socks server
#	- Paths - Paths are basically lists of networks and a socks server
#		  which can be used to reach these networks
#	- Default server - A socks server which should be used to access 
#			   networks for which no path is available
# Much more documentation than provided in these comments can be found in
# the man pages, tsocks(8) and tsocks.conf(8)

# Local networks
# For this example this machine can directly access 192.168.0.0/255.255.255.0 
# (192.168.0.*) and 10.0.0.0/255.0.0.0 (10.*)

local = LOC.LOC.239.0/255.255.255.0

# Paths
# For this example this machine needs to access 150.0.0.0/255.255.0.0 as 
# well as port 80 on the network 150.1.0.0/255.255.0.0 through
# the socks 5 server at 10.1.7.25 (if this machines hostname was 
# "socks.hello.com" we could also specify that, unless --disable-hostnames
# was specified to ./configure).

#path {
#	#reaches = 150.0.0.0/255.255.0.0
#	#reaches = 150.1.0.0:80/255.255.0.0
#	server = 138.251.239.14
#	server_type = 5
#	#default_user = delius
#	#default_pass = hello
#}

# Default server
# For connections that aren't to the local subnets or to 150.0.0.0/255.255.0.0
# the server at 192.168.0.1 should be used (again, hostnames could be used
# too, see note above)

server = LOC.LOC.239.14
# Server type defaults to 4 so we need to specify it as 5 for this one
server_type = 5
# The port defaults to 1080 but I've stated it here for clarity 
server_port = 1080

# $Id: socks.conf,v 1.28 2001/12/12 13:56:42 karls Exp $
#
# A sample socks.conf

# The configfile is divided into two parts; first misc. settings,
# then the routes.  Objects in '[]' are optional.
#
#
# recommended order is:
#	[debug]
#	[logoutput]
#	[resolveprotocol]
#
#	routes:
#		from to via
#		[command]
#		[extension]
#		[protocol]
#		[proxyprotocol]


debug: 1           # uncomment to enable debugging

logoutput: /tmp/sockslog  # users usually don't want to be bothered with that.

# What protocol should be used for resolving hostnames?  It's important
# to set this right.
#resolveprotocol: udp  # default
#resolveprotocol: tcp  # set this if your socksserver only supports socksv4.
#resolveprotocol: fake # set this if your clients can't access nameserver,
		       # neither directly nor proxied.



#
# the routes
#

# specifying routes for accepting remote connections (via bind()) is
# difficult since we can't know what the "to:" address is
# until we actually get the connection  Since we support letting
# the client accept connections both via the proxyserver and
# "directly" at the same time, we have two options though:
# a) specify a route for bind (only) first going via the proxyserver.
#    This will also handle "direct" connections.
# b) specify a route for bind (only) first going "direct".
#    This means clients will only be able to accept "direct"
#    connections.

# we want to accept remote connections via the proxyserver.
route {
	from: 0.0.0.0/0 to: 0.0.0.0/0 via: LOC.LOC.239.14 port = 1080
	proxyprotocol: socks_v5
	command: bind
}

# we do not want to accept remote connections via the proxyserver.
#route {
#	from: 0.0.0.0/0 to: 0.0.0.0/0 via: direct
#	command: bind
#}


# if you don't route all local connections via direct, you should
# at least route nameserver connections via direct connections if you
# can.  That can make for much better performance, depending on
# your setup.  Make sure the nameserver line is the first.
#
# Assuming your nameserver runs on address 10.1.1.1, you can do it like this:
#route {
#	from: 0.0.0.0/0 to: 10.1.1.1/32 port = domain via: direct
#}


# have a route making all connections to loopback addresses be direct.
#route {
#	from: 0.0.0.0/0   to: 127.0.0.0/8  via: direct
#	command: connect udpassociate # everything but bind, bind confuses us.
#}

# Our net is the 10.0.0.0/8 net, let clients going to local address go
# direct, not via server.
#route {
#	from: 0.0.0.0/0   to: 10.0.0.0/8   via: direct
#}

# for poor souls trapped behind a msproxy server.
#route {
#	from: 0.0.0.0/0   to: 0.0.0.0/0   via: 10.1.1.1 port = 1745
#	protocol: tcp			 # server supports tcp
#	proxyprotocol: msproxy_v2        # server runs msproxy_v2
#}

# clients going anywhere else go via server listening at
# IP address 10.1.1.1, port 1080.   Note that unless you have
# specified a direct connection for DNS, or the socksserver is resolvable
# without network traffic, you can't give a hostname for the socksserver,
# you must give a IP address.  (the reasons for that are logical enough,
# you would create a loop otherwise.)
route {
	from: 0.0.0.0/0   to: 0.0.0.0/0   via: LOC.LOC.239.14 port = 1080
	protocol: tcp udp                # server supports tcp and udp.
	proxyprotocol: socks_v5 # server supports socks v4 and v5.
	method: none #username		 # we are willing to authenticate via
					 # method "none", not "username".
}

# this is identical to the above, but it matches hostnames instead.
# This is if you have clients that are unable to resolve hostnames.
# It can be important that hostname routes come after address routes.
#route {
#	from: 0.0.0.0/0   to: .   via: 10.1.1.1 port = 1080
#	protocol: tcp udp                # server supports tcp and udp.
#	proxyprotocol: socks_v4 socks_v5 # server supports socks v4 and v5.
#	method: none #username		 # we are willing to authenticate via
#					 # method "none", not "username".
#}

# identical to above two routes, but using a httpproxy instead.
#

#route {
#	from: 0.0.0.0/0   to: 0.0.0.0/0   via: 10.1.1.1 port = 3128
#	command: connect		 # only thing a httproxy supports.
#	proxyprotocol: http_v1.0
#}

#route {
#	from: 0.0.0.0/0   to: .   via: 10.1.1.1 port = 3128
#	command: connect		 # only thing a httproxy supports.
#	proxyprotocol: http_v1.0
#}