On Mon, 1 Mar 2004, GG BB wrote:

> So I guess mine is not the 'standard' architecture for
> a NAT-VPN and Proxy ...
> Maybe the best solution would be keep them separate,
> and setting up a box that act 'only' as a Proxy ?

Sorry, you are mixing two problems.

There is no technical problem in running the proxy on a NAT-VPN gateway,
but you need to be careful with the source IP address assignment if the
proxy is to access servers over LAN IPSec VPN tunnels as the gateway
itself is usually not on an address part of the tunnel, and also the
firewalling gets a little complex as ju suddently have an alternative path
whereby traffic may be forwarded by the gateway so you better know the
access controls of the proxy at least as good as your firewalling rules.

Interception caching also works fine, at least with Free-S/WAN /
Open-S/WAN tunnels, and soon also with Linux-2.6 IPSec.

However, NAT-VPN gateway or not you can not use Interception
caching/proxying in combination with HTTP proxy authentication. If you
want to use HTTP proxy authentication there is no option but to have the
browsers configured to use the proxy as neither the browsers or the proxy
will accept authentication if not. When using interception the browsers
have no clue who they are supposed to authenticate to as for all they know
they are talking to the origin web server and not a proxy, and because of
the security implications of this HTTP REQUIRES the browser to not respond
to any HTTP proxy authentication challenges in such case.

> could someone provide their own experience in HOW and
> "WHERE" build a Proxy on a NET having a
> NAT-Firewall-VPN that is already working ?!

The logical place is on the local network, like any other local server. A
proxy is just a server which is accessed by your clients, and then going
out to the Internet to fetch the required content as a client of it's own.

So a proxy can be placed anywere where the following conditions are

a) All the clients who need to use the proxy can reach it

b) From where your policy allows access to the Internet.

c) Where it is suitable for your overall traffic flow. On the far side
(counted from the clients) of a heavily overloaded connection is for
example not a good place.

A transparently intercepting proxy has stricter requirements, and the
easies place to run it on the gateway, but if you can I would recommend
not due to the security implications if this gateway is also acting as a