On 15/01/2016 6:25 a.m., Robert Plamondon wrote: >> >> >> You *must* perform the NAT on the machine Squid is running on for intercept >> mode to work. >> >> Doing it on any other router along the way will not work. >> > > Unless I'm missing something, I'd phrase this differently: the NAT must not > be performed between the client and Squid. Squid is indifferent if NAT > occurs between itself and the server. So it's a matter of placing the two > functions in the right order along the network path. It makes more sense if you understand that "intercept" is an abbreviation for "NAPT interception" If you are considering the traffic leaving Squid as being viable for NAT interception back into Squid you are heading towards major forwarding loop problems. > > (Example: my VDSL modem performs NAT, and the intercepting Squid instance > on my Linux LAN gateway box neither knows nor cares.) > > If your router is some kind of Unix-like box, putting Squid on it may be > the most convenient path. If the router is underpowered, the local squid > can (often) be set up to avoid heavy lifting, with only a small RAM cache, > and forward everything to its smarter parent. (I haven't tried this on > anything in the low horsepower + high traffic realm, though.) > > For a "real" router like a Cisco box, you can configure it to route > appropriate traffic to the Squid box before performing NAT, using WCCP or > policy-based routing, and let the router perform the NAT itself on the > output of the Squid box. > > Good luck! > > Robert > > > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
