From owner-freebsd-net@FreeBSD.ORG Sun Apr 19 23:37:57 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30420106564A for ; Sun, 19 Apr 2009 23:37:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id D9F768FC16 for ; Sun, 19 Apr 2009 23:37:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so319814qwe.7 for ; Sun, 19 Apr 2009 16:37:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=sJ7Hk53iIuTO9CcGatboDWfTbznbCFB6OgFauyOoxvw=; b=fXPneYh2tJzRYQ+AbzoHAoUnGFZ9VkBgDk2qgMaVa2a+B5iTFl2OB6QUTZxBx/MRAs tKN9d0Ulgy4G3ICRy0zp7jTvJ2iQ/zqhKTSZNlww3CeCg12K8YYc9EVgFlKxMktoRIG8 iDuTDNIbTbgW0/TuwAhdohe2xxwk1FcbIkoR4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=iI96NE6oJNHu6k89vJ20esa2ImhNDLFpYVFEptOCBbHhEn/ez0S6jJlCFDdECK3mqX AB60dNC58OuZIBMjAwctVIKjsn0XMsNUJlCL6v+NZARhdZcNsFQN9rWKaev/1KMMNVq4 cJtWjNFqq64TUGToxSdF78mf50g2HnW3r8spI= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.224.29.13 with SMTP id o13mr5633760qac.206.1240182986749; Sun, 19 Apr 2009 16:16:26 -0700 (PDT) In-Reply-To: <49EA4FBC.4040202@ibctech.ca> References: <49EA4FBC.4040202@ibctech.ca> Date: Mon, 20 Apr 2009 07:16:26 +0800 X-Google-Sender-Auth: 213c84513f6ff946 Message-ID: From: Adrian Chadd To: Steve Bertrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: Route traffic on a gateway through SSH tunnel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 23:37:57 -0000 G'day; 2009/4/19 Steve Bertrand : > I have a Squid proxy/content filter at my office that I would like to > route all 80/443 traffic from my home connection, through the proxy. The > proxy and the termination point of my home connection are located in two > different PoPs, within different ASs. Eww. People still use Squid? > My desire is to have this proxy-routing enabled within the network > hardware, as to not need to set application layer details on the PC(s) > at home. > > At this point, I have the FBSD (7.2) gateway device set up with an SSH > tunnel. The local tunnel endpoint terminates on a LAN interface which > utilizes 1918 space. It listens for traffic on 172.16.250.1:80, and > forwards it to the proxyIP:8080. When I configure a workstation's > Firefox to use 172.16.250.1:80 as a proxy, everything works as expected. > > Now, I need to figure out a way so that the same setup will work, but > with no proxy configured within Firefox. > > At this time, I'm recompiling the kernel on the gateway device to > include IPFIREWALL_FORWARD. I'm going to try a fwd rule to pass all > traffic destined to *:80 to 172.16.250.1:80, in hopes that the traffic > will be first redirected to itself, and therefore through the SSH tunnel > to the proxy. > > My past experience with this however, is that FBSD will complain that > the dst IP doesn't reside on the box. > > Does anyone have any suggestions or comments they can share regarding > such a setup? Well, i'd first look at what you're doing with the "fwd" next-hop rewriting. All ipfw fwd does is next-hop rewriting with an optional redirect-to-local-socket-termination feature. You need to redirect to a local squid or some other proxy which can do the DNS lookups as required (if required!) and bounce the request upstream. I'd suggest setting up Squid on your local CPE to handle the "ipfw fwd any 127.0.0.1:3128" redirection (and use http_port 127.0.0.1:3128 transparent in squid.conf) and then configure squid with a parent proxy (cache_peer, disable never_direct, etc) to talk exclusively to your upstream proxy(ies). 2c, Adrian