dante   Frontpage - Dante - Download - Status - Support - Modules - Docs - Links - Survey - GDPR
 

The Dante FAQ page

Please send updates/corrections to dante-misc@inet.no or dante-bugs@inet.no.

Is there any documentation that describes how to setup the Dante SOCKS server or client?

The Dante configuration page describes how to configure Dante and covers most of the functionality offered by the latest version of Dante, including authentication, resource management and server chaining.

Guides for older Dante versions are also available via the Documentation overview page

Why does Dante create so many processes when I only have a few clients?

While it might initially look like the Dante server creates one process for each connection/client, that's not really so. The Dante server is targeted at users that need a socks server to handle a large amount of clients, and due to how this is designed in Dante, to serve one client it will need four processes. On the other hand, to serve 8 clients, it will also need four processes. And to serve 320 clients, it will need about 40 processes (or less. This is the current default, but it may be changed at compiletime). In addition, Dante tries to keep a few extra processes around to handle sudden bursts of clients.

How can I get information about Dante's current clients?

Sending the main Dante process a SIGINFO signal (or SIGUSR1 on platforms that do not have SIGINFO) will log information to Dante's configured logfile(s) about all current clients.

Why are there remaining sockd process after I kill Dante's main sockd process?

If you kill only the main Dante process, which in most cases is the recommended way to handle a restart, you may see that a few, or many, Dante processes continue to run. This is expected behaviour, and these processes will continue to run as long as they have existing SOCKS clients. Note that this should not prevent you from restarting Dante. After the restart, new clients will be handled by the new Dante server, while the old clients will continue to run in the old Dante server processes. See also the section on Restarting the Dante server.

How can I configure Dante to use more than one external IP address?

While Dante supports parsing of multiple external IP addresses or interfaces in it's sockd.conf file, it will by default only use the first address.

There are a few ways to make Dante use more than one address though.
  • Specify "external.rotation: route" in sockd.conf. Dante will then attempt to consult the routing table as to what interface the connection will go out on, and attempt to bind to an address on that interface. See the manpage for sockd.conf(5) for more information.
  • Specify "external.rotation: same-same" in sockd.conf (present in version 1.3.x of Dante). Dante will use the same IP address for connecting out as it accepted the client on. See the manpage for sockd.conf(5) for more information.
  • Use the Dante Redirect Module (sold separately) to specify what IP address Dante should use when connecting out on behalf of what client.

How can I get a rpm file for platform X

We provide binary files for a select number of platforms at the binary download page.

If you require an rpm file, it should be possible to manually build an rpm file using the following command:

rpmbuild -tb dante-1.4.0.tar.gz

Some system setup might be required for rpm building to work, depending on the platform.

Why is the client blocked/rejected?

If the SOCKS client is blocked, but you are unable to see why, the easiest way to find out is by enabling debug on the server (start it with "-d1"), which will produce a lot of information, including information on the requests sent by client, the responses returned by the Dante server and rules processing.

Another options is to temporarily add "log: connect disconnect iooperation" to all rules, including adding a "block" rule matching all addresses (0.0.0.0/0) and enabling logging in this rule too.

How can I socksify the whole system?

On some systems, doing the global equivalent of running a program with socksify is possible. This can be useful, but note that some programs might fail to work in a socksified environment. E.g., programs like rpm depend on a clean build-environment to get its (library) dependencies (according to Dag Wieers <dag@wieers.com.example.com>).

You should not attempt this unless you know what you are doing, as it is a potentially dangerous operation. The recommended way is to manually specify socksify when you start an application that you wish to add SOCKS support to. Should you however wish to try socksifying the whole system, it can be done in one of the two following ways (again, courtesy of Dag Wieers <dag@wieers.com.example.com>):

The most general approach is to set the LD_PRELOAD value in the shell startup file. This will have the same result as using the socksify program manually. For the Bourne shell/bash, the following lines can be added to the appropriate startup files, such as /etc/profile, ~/.profile, or ~/.bashrc. 

   LD_PRELOAD="libdl.so libdsocks.so"
   export LD_PRELOAD

On Linux, it is also possible to add the lines below to the /etc/ld.so.preload file, but again, do not do this unless you understand what you are doing. 

      libdl.so
      libdsocks.so

When all applications are socksified it might sometimes be necessary to turn of socksification. This can easily be achieved (in the Bourne shell/bash) with the following command: 

    unset LD_PRELOAD

How can I authenticate with PAM/LDAP?

Dante has direct support for LDAP-based authorization via the LDAP module. It is important to note that the LDAP module supports LDAP authorization, while the PAM/LDAP-combination supports LDAP authentication.

The LDAP-module is normally used together with GSSAPI-based authentication, using LDAP for authorization. The PAM/LDAP-combination on the other hand uses cleartext username/password authentication between the Dante server and the SOCKS client, and the Dante server authenticates the username/password against LDAP via PAM.

Via PAM, a wide range of possible authentication methods becomes possible, including LDAP. An example of how this can be configured has been provided by Alexander Cohen (A.Cohen@latrobe.edu.au.example.com).

First, make sure that you compile Dante with support for PAM. The configure script should do this for you if the PAM development libraries have been installed. Make sure you also have any PAM-devel packages installed, if they exist.

You will also have to add LDAP support to your PAM implementation, if it is not already there. Check if you have /lib/security/pam_ldap.so or the equivalent. If not, use pam_ldap from http://www.padl.com/.

pam_ldap gets its configuration from /etc/ldap.conf. Make sure you set host to your LDAP server, and base to your base DN. You can also set pam_filter and pam_group_dn to restrict logins to particular objecttypes or members of particular groups.

Point sockd at LDAP by creating /etc/pam.d/sockd. An example of this file is as follows: 

#%PAM-1.0
auth       sufficient /lib/security/pam_ldap.so
auth       required   /lib/security/pam_unix_auth.so try_first_pass
account    sufficient /lib/security/pam_ldap.so
account    required   /lib/security/pam_unix_acct.so
password   required   /lib/security/pam_ldap.so

Finally, you need to configure sockd.conf to restrict access based on PAM. This is accomplished with the following: 

# allowable authentication methods for socks-rules.
method: pam

# Client rules, controls who may connect
client pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        log: connect disconnect error
}

#
## everyone who authenticates is allowed to use tcp
## and udp
pass {
       from: 0.0.0.0/0 to: 0.0.0.0/0
       protocol: tcp udp
       log: connect disconnect error
       method: pam
}

# last line, block everyone else.  This is the default but if you provide
# one yourself you can specify your own logging/actions
block {
       from: 0.0.0.0/0 to: 0.0.0.0/0
       log: connect error
}

To authenticate against a Microsoft Active Directory server the following bare minimum example configuration for example.org with an active directory server at 10.0.0.1 is what you would require in /etc/ldap.conf: 

host 10.0.0.1
base cn=Users,dc=test,dc=org
rootbinddn cn=Administrator,cn=Users,dc=example,dc=org
pam_filter objectclass=user
pam_login_attribute cn

The password for the Administrator user should be specified in the file /etc/ldap.secret, which should have the mode 0600.

Additional documentation on the use of PAM in Dante can be found on the PAM authentication configuration page.

How can I authenticate with PAM/RADIUS?

Dante can be used with PAM RADIUS modules such as pam_radius_auth to authenticate users against a RADIUS server (such as FreeRADIUS).

With this type of authentication, username and password information is typically not kept in /etc/passwd, but in a separate database. This will have practical consequences for the PAM configuration because PAM modules such as pam_unix_auth that consult these files will not be able to access the user information required for authentication.

During PAM authentication, Dante requires two PAM functions to succeed in order for a user to be authenticated successfully, pam_authenticate() and pam_acct_mgmt(). This typically corresponds to a system PAM configuration with both an auth entry and an account entry.

If Dante blocks connections with the following message, this is an indication of the account entry not being present or not returning a successful value when authentication is attempted:

info: block(1): tcp/accept ]: 10.0.0.1.35019 10.0.0.1.54946: error after having read 22 bytes: pam_acct_mgmt(): Authentication failure

For pam_radius_auth, at least two entries like the following are needed:

auth    sufficient      pam_radius_auth.so
account sufficient      pam_radius_auth.so

Having additional entries in the PAM config might be necessary depending on the usage scenario, but at least the two entries above should be present for Dante to be able to authenticate users.

Additional documentation on the use of PAM in Dante can be found on the PAM authentication configuration page.

What do I do if I get "A token was invalid" warnings with Kerberos authentication?

"A token was invalid" warnings might occur in the log as this:

sockd[2222]: info: block(1): tcp/accept ]: 10.0.0.2.12345 10.0.0.1.1080: error after reading 1299 bytes in 1 second: recv_gssapi_enc_token(): gss_unwrap(): A token was invalid. unknown mech-code 0 for mech unknown.

Possibly this is caused by SOCKS clients that do not properly follow RFC 1961.

The Dante server has a built in compatibility option that can be used to handle one variation on the standard, via the necgssapi clientcompatibility option, which can be enabled in a client rule in this way:

client pass {
        from: 0.0.0.0/0 to: 0.0.0.0/0
        log: connect disconnect error data
        clientcompatibility: necgssapi
}

Why doesn't socksify work on cvs?

While the CVS program in itself can be socksified, it usually ends up calling a setuid program such as rsh which cannot.

Why will socksify not work on setuid programs like rsh, etc?

The reason is that these programs are setuid. Most systems will ignore the values that socksify set, making the result becomes the same as not using socksify on them.

Possible solutions are to strip off the suid bit (if possible), or to recompile the program with explicit SOCKS support. Adding "-ldsocks" to the link options is usually enough.

Why doesn't socksify work on HP-UX 11.00?

It might be necessary to install patch PHSS_22478, or one of its successors, which adds LD_PRELOAD support to the loader. (Thanks to albert chin (china@thewrittenword.com.example.com) for this tips.)

What causes unknown SOCKS version in request from client warnings?

These warnings are typically the result of non-SOCKS applications connecting to the Dante SOCKS server and attempting to send a non-SOCKS request. Some examples:

  • The warning unknown SOCKS version in request from client: 71 will be logged if a HTTP request is sent to a SOCKS server. The first character in a HTTP request is "G", which is encoded as the number 71 in ASCII.

  • The warning unknown SOCKS version in request from client: 69 will be logged if a HTTP CONNECT proxy request is sent to a SOCKS server, possibly as part of an https/TLS setup attempt. The first character in CONNECT is "C", which is encoded as the number 67 in ASCII.

I have problems rotating the server log files. What can I do except log via syslog?

Dante reopens the logfiles on SIGHUP, so it should be possible to rename the log file and send the Dante server a SIGHUP signal.

Another solution is suggested by Michael T. Babcock <mbabcock@fibrespeed.net.example.com>, which runs Dante under supervise with multilog for log rotation (based on size, not date). The following setup will run Dante under supervise (with a memory usage limit of 5 megabytes) and redirect log output to /var/log/dante/current. 

   /service/dante/run:

#!/bin/sh

exec 2>&1
exec softlimit -m 5000000 -p 30 -c 0 \
         /usr/sbin/sockd -f /etc/sockd.conf -N 1 -l # -d

   /service/dante/log/run:

#!/bin/sh

exec setuidgid logging multilog t /var/log/dante
For more information see, the daemontools home page.

What happens if I need to restart the Dante server?

If you kill one sockd process (any one), the rest of the processes will cope as best as they can.

This means that if you kill the main sockd process, clients that have already established their socks-session will continue to exist. The sockd processes handling these SOCKS clients will be orphaned (their parent pid will be init). They will not be able to accept new clients, but will continue to run as long as they have clients. This allows one to minimize the traffic interrupting effect of restarting the Dante server.

Once all clients have finished, these sockd processes will also die.

The Dante server can be restarted once the main sockd process has been killed. The newly started Dante server will then accept clients as usual, but will have no relation to existing processes created by the previous Dante server.

Using the Dante client library for firewall/proxy traversal

The Dante client library can be used to simplify applications that need to communicate via a proxy, or that need to bind ports on a proxy server (such as UPnP or SOCKS).

What does a socksified application need to care about?

A socksified application will normally work without any extra steps needing to be done, within the limits of the SOCKS standard. The exception to this is the following:

Applications combining non-blocking sockets with select(2)/poll(2) need to make sure they can handle the select(2)/poll(2) call being interrupted by a signal (i.e., failing with EINTR). This is due to how the Dante client library implements support for non-blocking connect(2).

Since correctly handling EINTR might be considered recommended practice regardless of whether the application is socksified or not, this should not be a problem for most applications, but some application will fail when socksified due to this.

Reporting problems or bugs in Dante

The Dante log files provide information that can be used to identify the source of application problems. Please follow the following steps to ensure that the log files provide as much useful information as possible when reporting bugs.

First of all, determine the name of the configuration file used by Dante. For the Dante client, this will typically be /etc/socks.conf. For the Dante server, the default file is /etc/sockd.conf. Either file should contain a line starting with the keyword "logoutput:", which specifies the location of the logfile.

Unless already present, add a line with the following contents to enable debug output:

debug: 2

After having enabled debug output, attempt to recreate the situation which caused the problem. Then examine the log files to determine if they contain information that can be used to identify the source of the problem.

If it looks like a bug, please verify the following:

  1. Make sure that you are using a supported version of Dante. Please consult the download page to check the status of the version you are using. If you are using a supported major release, check if there is a more recent bug fix release that fixes the problem you are experiencing.
  2. Consult the BUGS file included in the Dante distribution, and check the Dante status page to see if this is a known problem.

It might also help if you are able to provide additional information using one of the following tools. E.g., assuming the problem is in the client:

  • ktrace -di socksify <application>
  • truss -o truss.log -v all -lf socksify <application>
  • strace -o strace.log -tt -s200 -fF socksify <application>

If the problem or bug results in a crash or fatal application exit, please follow these steps to determine the reason for the failure:

  1. Ensure that coredump files are generated. This can usually be done with the following shell command: ulimit -c unlimited
  2. If the problem is reproducible, configure the Dante package to provide additional debugging information by running configure with the --enable-debug option and recompile.
  3. If the problem is with the client application, also compile the client program with the "-g" option, if possible.
  4. Verify that debugging is enabled in both the client and the server, as specified above.
  5. For each of the logfiles, perform the following command to ensure that the files will be empty before trying to reproduce the problem:
    cp /dev/null <logfile>
  6. If a coredump is generated, perform the following command:
    gdb <failing program> <coredump>
  7. A new interface should appear. Type the following command and store the output in a file:
    backtrace -50
  8. For Solaris, use the following commands, if gdb is not installed:
    pstack <coredump>
    pflags <coredump>

Copyright © 1998-2024 Inferno Nettverk A/S