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

The Dante FAQ page

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

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. See also 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.

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, only a little of which will be related to blocking clients.

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 none

# allowable authentication methods for client-rules.
clientmethod: pam none

# Client rules, controls who may connect
#
## 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.

Technical Problems

Automatically socksifying an application might not always work.

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 or ssh, which cannot.

Why will socksify not work on setuid programs like ssh, 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.)

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.

Administration

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. This is due to how the Dante client library implements support for non-blocking connect(2). This is however recommended practice regardless of whether the application is socksified or not.

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 -v all -lf socksify <application>
  • strace -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-2012 Inferno Nettverk A/S