/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! */
Ranieri Argentini <[EMAIL PROTECTED]> wrote:
>
> I have been trying for a while now to get my ICQ to work with SOCKS to
> no avail.
Since I'm the local "proxy moron" at my workplace, I suppose I could try
to lend a hand (paw?).
> Everything works fine with the module btw.
Note that the module does work fine with most of the protocol features,
but one notably-missing feature is file transfers. The module doesn't
support them. If they are important to you, then you can go ahead and
go through all this; if you don't care about them, then why are you
messing with a system that works the way you want? Heh...
> Sep 23 13:23:49 flem Socks5[30695]: TCP Connection Request: Bind (10.10.10.3:2065 to
>205.188.147.46:80) for user
> Sep 23 13:23:49 flem Socks5[30695]: TCP Connection Terminated: Abnormal
>(10.10.10.3:2065 to 205.188.147.46:80) for user : 0 bytes out, 0 bytes in
This is the real cause for the failure: The client wants to bind a
socket on the server, and it's failing (for reasons that apparently
aren't given in the log).
The only thing that comes to mind is, are you firewalling ports in the
1024-4999 range, not allowing them to connect to the server? Masq
shifts all port-usage to the 61000-65000 range, so if you are only
allowing those ports in, your masq will work, but your SOCKS will not.
Then again, firewalling those ports would make other local services on
the masq box fail, too (like sendmail or DNS).
> Behind firewall, SOCKS5, timeout 30 secs, correct hostname, port 1080,
> resolve IP (it's dynamic).
I'm not sure what the "resolve IP" setting really does; I turn it off.
Osman Ullah <[EMAIL PROTECTED]> wrote:
>
> I found that setting up the Socks5 can be pretty complicated.
I suppose I made it out to be easier than it really is. My example
config works quite well for me; I assume it would work well for any
small network.
> I had it working fine with a config similar to Fuzzy's, but then I had
> to add password authentication for security reasons (some IRC network
> wouldn't let me in if I didn't).
This is confusing to me. A SOCKS server uses password authentication in
order to figure out whether a particular user behind the firewall is
*allowed* to use the SOCKS server at all. The username gets logged in
the logs, but it does NOT get sent to anyone outside the network!
IRC normally uses "ident" protocol to determine the "real user" that is
attached to a socket connection. Since the SOCKS server runs as root
(though it doesn't have to), the owner of any connection via SOCKS will
appear to be "root", to the external network, unless SOCKS does some
amazing things with setuid changes that I don't know about...
Well, anyway, password authentication should still work, regardless, but
your users have to have passwords on the firewall box.
> Now ICQ only works with socks4...I dunno why.
ICQ doesn't have full functionality unless you use SOCKS5. SOCKS4 only
proxies TCP connections, and as we know, ICQ uses UDP extensively.
Still, your MASQ might be taking care of the UDP side of things.. Hmm.
> Even after reading the docs, I don't quite understand how the
> "interface" lines of the socks5.conf file work...how does it know
> which is a source and which is a destination line?
Good question. I believe the answer is that the "interface" line does
not specify a source or destination, it simply gives the answer "What IP
addresses am I allowed to see coming from this interface?" If the SOCKS
server sees some incorrect traffic, it'll ignore it. It also answers
the question, "Which interface should I use if I want to bind IP address
xx.xx.xx.xx?"
Normally the SOCKS5 server will scan all interfaces and examine their
netmasks, and that tells it everything it needs to know. I don't use
the "interface" line at all. Allowing or disallowing traffic is the
responsibility of the "permit" and "deny" keywords.
> I had to change my set up to a multi-homed setup (multi-homed means
> you have 2 ethernet cards...single-homed means you only have one).
Actually, any masq system is a multi-homed setup. Multi-homed means you
hvae two network *interfaces*. If one of them is eth0, and the other is
ppp0, you are multi-homed.
I wonder if some of these problems come about because the socks5 daemon
is started *before* the ppp0 interface is created, so it doesn't see it?
> auth - - u
> : the u sets password authentication...set it to - or n if you don't want any.
I'm still amazed that this makes IRC work.
> noproxy 192.168.0. -
> : don't use the proxy when accessing the intranal network...this line might
> : be just for clients, not for the server...I have it in here anyways.
No, the "socks5.conf" file is used for the server. Client programs use
the "libsocks5.conf" file to guide them.
The "noproxy" line, now that I think about it, is not necessary for most
SOCKS servers. It is only needed in a setup like I have, where I am
behind a corporate firewall (*another* SOCKS server), and I need to
forward my SOCKS connections over to the next server in line. The
"noproxy" line then tells my local SOCKS server that chaining to another
server is not necessary, for the given set of IP addresses. If you
don't have any "socks4" or "socks5" config entries, then you don't need
any "noproxy" entries, either.
A SOCKS server can be multi-purpose. It can be valid for an internal
client to connect to the server, and tell it to connect back to some
other host on the internal network, essentially "hiding" behind the
SOCKS server. More importantly, it is also possible for a host OUTSIDE
your local network to connect to your SOCKS server, and request to come
in! You must take steps to prevent this!
> interface 192.168.0. - 192.168.0.1
> : says that only clients from the internal network can send requests on the
> : ethernet card with the ip 192.168.0.1
Since this is the same conclusion that the SOCKS server will reach by
examining the enterface's netmask, this line isn't really necessary.
> interface - - 128.61.56.27
> : says that 128.61.56.27 is the outgoing port for the proxy. Again, NEC's
> : documentation is very poor here, and I am not sure how it knows the
> : difference between the two lines...I guess if a request is coming in on
> : one interface, it can't go out on the same one...I dunno.
The "interface" table is used for *both* purposes. When an incoming
connection is received, it is compared to the "interface" lines to see
if it is valid. When the servers wants to make an outgoing connection,
it consults the interface table to see which interface should be used
for sending that traffic.
A valid use might be, if you have a 10.20.30.40 interface, and it
gateways to a huge 10.*.*.* network. In such a case, you would need to
tell the SOCKS server that such IP addresses can be seen from that
interface, and should be gatewayed to that interface, because otherwise
it would have no way to know.
> permit u - 192.168.0. - - - osman
> : permits requests from the internal network...but also says all requests
> : must be authenticated from the user osman
>
> deny - - - - - -
> : denies everything else...not sure this line is necessary
That line *is* necessary in order to prevent people from the external
net from reaching your SOCKS server and trying to get in.
In my setup, I simply firewall port 1080 on the external interface. But
it never hurts to be thorough.
Port 1080 is above the 1024 "high-port" mark, so you should take care
that it is properly firewalled.
Here's hoping this (long) post helps someone out there...
--
[EMAIL PROTECTED] (Fuzzy Fox) || "Just about every computer on the market
sometimes known as David DeSimone || today runs Unix, except the Mac (and
http://www.dallas.net/~fox/ || nobody cares about it). -- Bill Joy '85
_______________________________________________
Masq maillist - [EMAIL PROTECTED]
Admin requests can be handled at http://www.indyramp.com/masq-list/ -- THIS INCLUDES
UNSUBSCRIBING!
or email to [EMAIL PROTECTED]
PLEASE read the HOWTO and search the archives before posting.
You can start your search at http://www.indyramp.com/masq/
Please keep general linux/unix/pc/internet questions off the list.
