Problems with SOCKS Authentification

please go into the command line and do a tail /var/log/daemon, then try to use it with authentication. Post the output here please  [;)]

I'm also having the same problem.


Feb 15 13:20:05 nat sockd[582]: got accept(): XXX.177.2.XX.4618
Feb 15 13:20:05 nat sockd[584]: pass(1): accept: XXX.177.2.XX.4618 -> XXX.177.2.XXX.1080
Feb 15 13:20:05 nat sockd[584]: recv_methods(): sending authentication reply: VER: 5 METHOD: 2
Feb 15 13:20:05 nat aua[245]: flushing cache
Feb 15 13:20:05 nat sockd[585]: received request: VER: 5 CMD: 1 FLAG: 0 ATYP: 3 address: dallas.tx.us.undernet.org.6667
Feb 15 13:20:05 nat sockd[585]: addressmatch(): gethostbyname(dallas.tx.us.undernet.org): Unknown host
Feb 15 13:20:05 nat sockd[585]: addressmatch(): gethostbyname(dallas.tx.us.undernet.org): Unknown host
Feb 15 13:20:05 nat sockd[585]: block(0): connect: username@XXX.177.2.XX.4618 -> dallas.tx.us.undernet.org.6667
Feb 15 13:20:05 nat sockd[585]: send_response(): sending response: VER: 5 REP: 2 FLAG: 0 ATYP: 3 address: dallas.tx.us.undernet.org.6667
Feb 15 13:20:05 nat sockd[584]: sending request to mother
Feb 15 13:20:05 nat aua[20739]: U:username F:socks R[:$]K C:auth by aua.local


the error on the client I get is Firewall: Connection rejected/failed
 
------------------
-Bryan www.apachetoolbox.com 

[This message has been edited by ApacheToolbox (edited 15 February 2001).]

apachetoolbox: the auth part works ok. (Feb 15 13:20:05 nat aua[20739]: U:username F:socks R[:$]K C:auth by aua.local).

But the Astaro box is not able to resolve the name dallas.tx.us.undernet.org into an IP address. Check your DNS settings. Workaround would be to use an IP address instead of a name. In this case:

tom@duncanthrax:~$ nslookup dallas.tx.us.undernet.org
Server:  localhost
Address:  127.0.0.1

Non-authoritative answer:
Name:    us.undernet.org
Addresses:  207.173.16.33, 207.96.122.250, 205.252.46.98, 207.110.0.52
          205.188.149.20, 204.127.145.17, 216.24.134.10, 199.170.91.114
Aliases:  dallas.tx.us.undernet.org

apachetoolbox: the auth part works ok. (Feb 15 13:20:05 nat aua[20739]: U:username F:socks R[:$]K C:auth by aua.local).

But the Astaro box is not able to resolve the name dallas.tx.us.undernet.org into an IP address. Check your DNS settings. Workaround would be to use an IP address instead of a name. In this case:

tom@duncanthrax:~$ nslookup dallas.tx.us.undernet.org
Server:  localhost
Address:  127.0.0.1

Non-authoritative answer:
Name:    us.undernet.org
Addresses:  207.173.16.33, 207.96.122.250, 205.252.46.98, 207.110.0.52
          205.188.149.20, 204.127.145.17, 216.24.134.10, 199.170.91.114
Aliases:  dallas.tx.us.undernet.org

You'll also notice that many of the undernet servers doesn't like socks5 connections.
;-)
Using a normal linux distro with socks5 you'll see many messages in /var/log regarding socks connections from ip.of.the.undernet.server - if the result is something else than "connection refused" the undernet will drop your connection.

Dunno why they don't like socks anyway...



------------------
Over and Out.

I got:

Feb 19 15:40:34 asl sockd[9590]: got accept(): 192.168.201.1.49123
Feb 19 15:40:34 asl sockd[9661]: pass(1): accept: 192.168.201.1.49123 -> 192.168.201.98.1080
Feb 19 15:41:04 asl sockd[9661]: pass(1): accept abort: 192.168.201.1.49123 -> 192.168.201.98.1080: negotiation timed out

Another output (client centericq)
prev. was from gnapster

Feb 19 16:01:30 asl sockd[14435]: got accept(): 192.168.201.1.49191
Feb 19 16:01:30 asl sockd[14500]: pass(1): accept: 192.168.201.1.49191 -> 192.168.201.98.1080
Feb 19 16:01:30 asl sockd[14500]: recv_methods(): sending authentication reply: VER: 5 METHOD: 255
Feb 19 16:01:30 asl sockd[14500]: pass(1): accept abort: 192.168.201.1.49191 -> 192.168.201.98.1080: socks protocol error

icebear:

both connections are dropped before any authentication has taken place.

it looks like both clients don't do SOCKS5 protocol negotiation correctly. Maybe they talk SOCKS4, because this may work when user auth is switched off.

plz check the docs of both proggies if they support SOCKS5 correctly.

I'm having about the same problem, but with AIM.  After reading this, I went back and used an IP address insted of a hostname and BWAM it works.  In the /var/log/daemon I get the same GETHOSTBYNAME errors.

This problem only seams to come up when I use Socks5 with auth on.  If I use plain Socks4 without authentication it works fine.

this is something I forgot to add to the docs  [;)]

If you do NOT use user authentication then you should leave username and password fields in your client empty. Some clients have an additional checkbox for "send username and password", but most simply check if the username field is empty or not.

In a nutshell:

If you do not use user authentication, ASL's SOCKS will support SOCKSv4 as well.

If you do user authentication on the ASL, then SOCKS5 clients MUST NOT send usernames and passwords.

k got it.

I will see if I can reproduce that behaviour on one of our systems.
Thanks to you for taking the time to pursue this  [;)]

/tom

Maybe I should have been more clear....

If I turn on the authentication in the firewall for SOCKS, then use Socks 5 on the client with the correct username and password, using a full domain name, it fails with the error above.

If I turn on the authentication in the firewall, and use Socks5 with a IP and with the correct username and password it works fine.

If I disable authentication in the firewall, and use Socks5 with a full domain name and with a blank username and password it fails.

If I disable authentication in the firewall, and use Socks5 with an IP address and with a blank username and password it works fine.

If I disable authentication in the firewall and use Socks4 with a full domain name and with no username and password it works fine.

The IP used for testing is: 152.163.242.24
The domain name used: login.oscar.aol.com

Client App:  AIM

It seams to be a problem with the Socks5 hostname lookup?

I hope this is a little more understandable.

OK, I have looked into this. From the NEC SOCKS FAQ:

What does that mean ?

1. SOCKS4 client MUST resolve names themselves, thus the Astaro Box has no problems with them.

2. SOCKS5 client applications CAN resolve hostnames themselves, but they have the option to pass the unresolved name on to the SOCKS5 server, and let him do the resolving. The Astaro Box will be able to resolve names if the DNS proxy is properly configured.

Obviously, your AIM clients resolves names himself if you configure him without username and password authentication, or with the SOCKS4 protocol.   [;)]

[This message has been edited by tom (edited 12 March 2001).]