Hi, I'm using squid 3.3.8 (sorry if this is not the latest; sticking with a Debian-packaged Squid) as a transparent proxy, using IPTables to pull users in. I'm also using UFDBGuard, and everything so far has been working and scaling great. My users connect through a VPN endpoint located on the box. I have several such boxes. There's some session management stuff for connected users that's running on the box, and my users should be able to reach that session management stuff regardless Here's a config for squid: http_port 13100 http_port 12600 intercept acl Safe_ports port 80 acl tp_ipv6 dst ipv6 acl vpns src 44.0.0.0/8 acl CONNECT method CONNECT http_access allow vpns http_access deny all coredump_dir /var/spool/squid3 visible_hostname futuredebian tcp_outgoing_address REDACTED !to_ipv6 unique_hostname REDACTED access_log daemon:/var/log/squid/6/access.log squid cache_log /var/log/squid/6/cache.log max_filedesc 8192 pid_filename /usr/local/etc/squid/0/squid.pid hosts_file /etc/hosts url_rewrite_program /usr/local/ufdbguard/bin/ufdbgclient -C -l /var/ufdbguard/logs url_rewrite_children 128 startup=6 concurrency=8 And /etc/hosts: 127.0.0.1 localhost REDACTED REDACTED cdn.REDACTED.com So, the cdn URL resolves, externally, to an address that's not serving the content, so the client browsers will actually send out the request over the VPN, where squid will catch it. Ideally, squid would then look in /etc/hosts to see that the CDN is running on that box and send it over to the local webserver which is configured to receive it (tested this with telnet; local webserver is happy). Unfortunately, squid seems to be ignoring /etc/hosts and actually trying to go out and talk to that destination address; squid gives the user: "Connection to REDACTED failed". Does the 3.3.8 hosts_file directive not work? Or perhaps not work for intercept type proxies? I am open to other ways of configuring squid to force all traffic destined to the "cdn" to be pointed at a local webserver running on the box. -- Every dogma has its day -- DrWho