Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 May 1999 09:22:29 -0400 (EDT)
From:      Rich Fox <rich@f2sys.net>
To:        freebsd-net@FreeBSD.ORG
Subject:   Re: socks5 problems (auth) [Solved]
Message-ID:  <Pine.BSF.4.05.9905260843050.66197-100000@ppp-rich.ari.net>
In-Reply-To: <Pine.BSF.4.05.9905250833520.60131-100000@ppp-rich.ari.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

Thanks for the responses...

The problem simply appeared to be that I hadn't 'completed' my
configuration, that is, I needed to change the permit line to permit
machines from the 192.168.1. network to access the socks server. [d'oh!]

For some reason, I assumed that the permit line would work as in this
configuration, which it didn't. When I changed the permit line to read:

permit - - 192.168.1. - - - 

It started working fine. 

(Incidentally I know from the socks5 lists that
other platforms running IP Aliasing and socks5 simultaneously caused
problems, in this case [FreeBSD 3.1] it 'seems' to work, (that is, the
quality of the stream is rather low, but that may be attributable to the
youth of the Quicktime Streaming Media implementation). Turning off IP
Aliasing in the kernel is *not* an option since our subnet workstations
are MacOS, whose apps are either non-socks5 capable (e.g. Netscape 4.08
MacPPC appears to be only socks4 compatible, or at least that's what the
socks log seems to suggest), nor is there a SocksCAP application 
available in any case. The only reason that we really need socks5 is
because we work a lot with QT (which appears to be the only pertinent
media type that we can't get through kernel IP Aliasing) and expect to be
working with QT4 streaming media, if we can't see it coming off the net,
we're gonna be in trouble with our clients.

I am still interested in why RealAudio via RTSP works well through kernel
IP Aliasing while Quicktime Streaming via RTP-RTSP doesn't work at all,
I guess it's the RTP part ;)

Thanks again,
Rich.

On Tue, 25 May 1999, Rich Fox wrote:

> Hi,
> 
> I have sent this through the freebsd-questions channel, and received
> helpful, but not definitive, information. I have socks5 running (v1.0r9)
> on a freeBSD 3.1 box. The problem I am having is that I have never been
> able to configure it to accept a connection without requiring
> authorization from the client, (alas, I have never been able to configure
> it to accept a connection and actually act as a proxy--authroization or 
> not!).
> I understand the risk of leaving the proxy wide open, but I can't get
> anything to work anyways. In any case here is my *.conf file...
> 
> # Authentication entries
> auth - - -
> 
> # Access entries
> permit - - 0.0.0.0/0.0.0.0 - -
> 
> # route entries
> route 192.168.1. - 192.168.1.1
> route - - 123.456.789.123
> 
> This is a multi-homed host (IP aliasing), I simply want to allow a
> connection from 192.168.1.n to a server on the other side. The other
> side's interface is at 123.456.789.123 and obviously 192.168.1.n's
> interface is at 192.168.1.1. The system is running ip aliasing and IPFW,
> however, IPFW has been wide open for these tests.
> 
[snip]
> Thanks,
> Rich.
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
> 
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9905260843050.66197-100000>