From owner-freebsd-net Wed May 26 6:18:53 1999 Delivered-To: freebsd-net@freebsd.org Received: from web4-1.ability.net (web4-1.ability.net [216.32.69.9]) by hub.freebsd.org (Postfix) with ESMTP id C45E514A2E for ; Wed, 26 May 1999 06:18:51 -0700 (PDT) (envelope-from rich@f2sys.net) Received: from ppp-rich.ari.net (ppp-rich.ari.net [198.69.193.148]) by web4-1.ability.net (8.9.1/8.9.1/Pub) with ESMTP id JAA15773 for ; Wed, 26 May 1999 09:06:38 -0400 (EDT) Date: Wed, 26 May 1999 09:22:29 -0400 (EDT) From: Rich Fox X-Sender: rich@ppp-rich.ari.net To: freebsd-net@FreeBSD.ORG Subject: Re: socks5 problems (auth) [Solved] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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