On 6/03/2015 1:19 a.m., Monah Baki wrote: > Hi all, can anyone verify if this is correct, need to make ure that users > will be able to access the internet via the squid. > > Running FreeBSD with a single interface with Squid-3.5.2 > > Policy based routing on Cisco with the following: > > > interface GigabitEthernet0/0/1.1 > > encapsulation dot1Q 1 native > > ip address 10.0.0.9 255.255.255.0 > > no ip redirects > > no ip unreachables > > ip nat inside > > standby 1 ip 10.0.0.10 > > standby 1 priority 120 > > standby 1 preempt > > standby 1 name HSRP > > ip policy route-map CFLOW > > > > ip access-list extended REDIRECT > > deny tcp host 10.0.0.24 any eq www > > permit tcp host 10.0.0.23 any eq www > > > > route-map CFLOW permit 10 > > match ip address REDIRECT > set ip next-hop 10.0.0.24 > > In my /etc/pf.conf > rdr pass inet proto tcp from 10.0.0.0/8 to any port 80 -> 10.0.0.24 port > 3129 > > # block in > pass in log quick on bge0 > pass out log quick on bge0 > pass out keep state > > and finally in my squid.conf: > http_port 3128 > http_port 3129 intercept > > > > And for testing purposes from the squid server: > ./squidclient -h 10.0.0.24 -p 3128 http://www.freebsd.org/ > > If I replace -p 3128 with -p 80, I get a access denied, and if I omit the > -p 3128 completely, I can access the websites. If you omit the -p entirely squidclient assumes "-p 3128" (the proxy default listening port), so it works exactly the same as if you had used -p 3128 explicitly. If you use -p 80 you also need to change the pther parameters so they generate port-80 syntax message: - the -h with IP or hostname of the remote web server, and - the URL parameters being a relative URL, and - the -j parameter with Host: header domain name of the server ... eg. squidclient -h www.freebsd.org -j www.freebsd.org -p 80 / NP: if your squidclient is too old to support -j, use this instead: -H 'Host: www.freebsd.org\n' ** this test should work from the squid box without having gone through the proxy. Only from the client machine should it work *with* NAT passing it through the proxy. Using a proxy syntax message sent directly to the proxy receiving port, or with the proxy as receiving IP on port 80 (NAT'ed to Squid) is a guaranted forwarding loop failure. That doesn't fix your clients issue, but hopefully makes it clear that the above desribed test is broken enough to prevent you identifying when the client issue is fixed if that happens on some change. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
