danted and socks proxies - problems (repost)

Hi,
I want to use Firefox with socks proxies.
I understand I need a local socks server like danted, but so far I have been
unable to make the system work. I have danted installed and I think the
configuration is correct, but I really don't know how to be sure that the
proxy setup in Firefox would work; public proxies are a hit-or-miss
proposition at best.

(doesn't work with Konqueror either using dante-client)

I think that Firefox has built-in socks support, so dante-client would not
be required.

I have used tools like tcptraceroute, but don't know if that would tell me
correctly that the public proxy is indeed functioning as I would need to
use it with socks.

I set up a socks proxy in firefox and it seems to connect to a given
website, but the page does not display.

In Firefox the socks setup is looking a the server at 127.0.0.1, port 1080.
I chose several listed public socks proxies and got the results above.

I should add that I am using a router into a cable modem and also running a
firewall on the router and on my local Debian Sarge machine, with a 2.6.15
kernel and using iptables set up with Arno's firewall script; possibly the
firewall is really the problem, but I want to at least be assured that my
danted setup is correct.

Here is my danted setup:

# all outgoing connections from the server will use the IP address
# 195.168.1.1
#external: 192.168.1.1
external: eth0


# methods for socks-rules.
method: username none #rfc931

# methods for client-rules.
clientmethod: none

#or if you want to allow rfc931 (ident) too
#method: username rfc931 none

#or for PAM authentification
#method: pam

#
# An important section, pay attention.
#

# when doing something that can require privilege, it will use the
# userid:
user.privileged: root

# when running as usual, it will use the unprivileged userid of:
user.notprivileged: nobody

# If you compiled with libwrap support, what userid should it use
# when executing your libwrap commands? "libwrap".
user.libwrap: nobody


#
# some options to help clients with compatibility:
#

# when a client connection comes in the socksserver will try to use
# the same port as the client is using, when the socksserver
# goes out on the clients behalf (external: IP address).
# If this option is set, Dante will try to do it for reserved ports aswell.
# This will usually require user.privileged to be set to "root".
#compatibility: sameport

# If you are using the bind extension and have trouble running servers
# via the server, you might try setting this. The consequences of it
# are unknown.
#compatibility: reuseaddr

#
# The Dante server supports some extensions to the socks protocol.
# These require that the socks client implements the same extension and
# can be enabled using the "extension" keyword.
#
# enable the bind extension.
#extension: bind


#
#
# misc options.
#

# how many seconds can pass from when a client connects til it has
# sent us it's request? Adjust according to your network performance
# and methods supported.
connecttimeout: 30 # on a lan, this should be enough if method is "none".

# how many seconds can the client and it's peer idle without sending
# any data before we dump it? Unless you disable tcp keep-alive for
# some reason, it's probably best to set this to 0, which is
# "forever".
#iotimeout: 0 # or perhaps 86400, for a day.
iotimeout: 86400

# do you want to accept connections from addresses without
# dns info? what about addresses having a mismatch in dnsinfo?
#srchost: nounknown nomismatch

#
# The actual rules. There are two kinds and they work at different levels.
#
# The rules prefixed with "client" are checked first and say who is allowed
# and who is not allowed to speak/connect to the server. I.e the
# ip range containing possibly valid clients.
# It is especially important that these only use IP addresses, not
hostnames,
# for security reasons.
#
# The rules that do not have a "client" prefix are checked later, when the
# client has sent its request and are used to evaluate the actual
# request.
#
# The "to:" in the "client" context gives the address the connection
# is accepted on, i.e the address the socksserver is listening on, or
# just "0.0.0.0/0" for any address the server is listening on.
#
# The "to:" in the non-"client" context gives the destination of the clients
# socksrequest.
#
# "from:" is the source address in both contexts.
#


# the "client" rules. All our clients come from the net 10.0.0.0/8.
#

# Allow our clients, also provides an example of the port range command.
#client pass {
# from: 10.0.0.0/8 port 1-65535 to: 0.0.0.0/0
# method: rfc931 # match all idented users that also are in
passwordfile
#}

# This is identical to above, but allows clients without a rfc931 (ident)
# too. In practise this means the socksserver will try to get a rfc931
# reply first (the above rule), if that fails, it tries this rule.
client pass {
from: 192.168.1.0/24 port 1-65535 to: 0.0.0.0/0
}


# drop everyone else as soon as we can and log the connect, they are not
# on our net and have no business connecting to us. This is the default
# but if you give the rule yourself, you can specify details.
#client block {
# from: 0.0.0.0/0 to: 0.0.0.0/0
# log: connect error
#}


# the rules controlling what clients are allowed what requests
#

# you probably don't want people connecting to loopback addresses,
# who knows what could happen then.
block {
from: 0.0.0.0/0 to: 127.0.0.0/8
log: connect error
}


#end of config

Thanks!
--
If you wrestle in the mud with a pig.
you both get dirty, and the pig likes it.

-- Dave Dawson