Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Apr 2009 07:16:26 +0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Steve Bertrand <steve@ibctech.ca>
Cc:        FreeBSD Net <freebsd-net@freebsd.org>
Subject:   Re: Route traffic on a gateway through SSH tunnel
Message-ID:  <d763ac660904191616p499a5730odaa96cb8fbf18e9d@mail.gmail.com>
In-Reply-To: <49EA4FBC.4040202@ibctech.ca>
References:  <49EA4FBC.4040202@ibctech.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
G'day;

2009/4/19 Steve Bertrand <steve@ibctech.ca>:

> 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



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