On 25/08/2014 2:22 p.m., orientalsniper wrote: > nginx is serving as reverse proxy listening on 10.2.0.4-10.2.0.9 HTTP > for some games patches. > > pfSense serves as firewall, captive portal and among other services. > > By NAT, I think you mean pfSense is doing it? pfSense is 10.0.0.1, > 10.1.0.1 and 10.2.0.1. > I have a NAT rule in pfSense to redirect all LAN2 HTTP traffic to > 10.2.0.2 (port 3128). > Great, that clarifies a lot. The problem is that NAT is being done on a separate box from Squid. The current Squid attempt to be as fully transparent as possible in intercept/transparent mode. That includes ensuring the domain/IP the client was contacting is actually the one Squid is using too - that is mandatory due to CVE-2009-0801 issues. With NAT on a separate box Squid only knows its own IP as the destination. So on the outbound things get looped. What you need to do to fix this is move the NAT rule changing port to 3128 onto the Squid VM. Have pfSense route port 80 traffic with 10.2.0.2 as the gateway router (policy routing) unless it came from 10.2.0.2 in the first place. After that your proxy should be usable. But there are some additional security issues that need resolving as well: 1) renumber the interception port in Squid to something other than 3128. Squid needs to use 3128 for forward-proxy traffic from the clients, manager API acces, icons, etc. 2) update the Squid VM firewall to prevent external machines directly accesing the intercept port you choose. It is only needed to be used by packets between Squid and the firewall on the same machine. If any outside machines do access it you will have looping problems and potentially a DoS happening. > WORK-PC (10.1.0.3) ACL was redudant and I forgot to delete it, since > it's part of 10.0.0.0/8 > > Regarding "tcp_outgoing_address 127.0.0.1" that was one of my > attempts to fix my issue, I've tried 10.2.0.2 also. You should not need to set outgoing IP at all. Remove that before testing the above changes. HTH Amos
