On Jul 25, 2014, at 3:32 AM, Amos Jeffries <squ...@treenet.co.nz> wrote:
> On 25/07/2014 10:15 a.m., Israel Brewster wrote: >> I have been using Squid 2.9 on OpenBSD 5.0 for a while as a transparent >> proxy. PF on the proxy box rdr-to redirects all web requests not destined >> for the box itself to squid running on port 3128. Squid then processes the >> request based on a series of ACLs, and either allows the request or >> redirects (deny_info ... all) the request to a page on the proxy box. >> > > There are some big changes in OpenBSD between those versions. Have you > tried divert-to in the PF rules and tproxy option on the Squid http_port ? > > Amos I figured as much. Thus the reason I am going back to just trying to get a basic setup working. So I have now gone back to the default config files for pf and squid. First, I set up PF to just do basic routing (no squid) and made sure that worked by adding the single line (along with some macros): match out on $outsideIF from !(outsideIF:network) nat-to $OutsideIP I was then able to properly access webpages through the box. So far so good. I then followed this guide: http://wiki.squid-cache.org/ConfigExamples/Intercept/OpenBsdPf, which uses tproxy and divert-to, as you suggested. Other than the changes listed in the guide, I also stripped down the squid http_access rules to the basic "block all but a few" set I listed earlier, and added an extra http_port line (with no modifiers) to avoid errors on startup. The only set skip rule I have in PF is set skip on lo, which should be fine (I think). At this point, from what I can tell, everything was broken. Attempting to connect to a website through the box now returns (using firefox) "Unable to connect. Firefox can't establish a connection to the server at ..." regardless of the site I attempt to connect to. Perhaps more to the point, squid running in debug mode shows no indication of an attempted connection. looking at the PF.log shows the following when I attempt to connect to a webpage: 08:28:50.954386 rule 0/(match) match in on em0: 192.168.10.51.49635 > 96.30.50.156.80: S 2366946536:2366946536(0) win 65535 <mss 1460,nop,wscale 4,nop,nop,timestamp 721039242 0,sackOK,eol> (DF) 08:28:50.954393 rule 2/(match) pass in on em0: 192.168.10.51.49635 > 96.30.50.156.80: S 2366946536:2366946536(0) win 65535 <mss 1460,nop,wscale 4,nop,nop,timestamp 721039242 0,sackOK,eol> (DF) 08:28:50.954398 rule 2/(match) pass in on em0: 192.168.10.51.49635 > 96.30.50.156.80: S 2366946536:2366946536(0) win 65535 <mss 1460,nop,wscale 4,nop,nop,timestamp 721039242 0,sackOK,eol> (DF) Where rule 0 is the logging rule (match log (matches) inet from 192.168.10.0/24 to any) and rule 2 is the divert-to rule (pass in quick inet proto tcp from 192.168.10.0/24 to any port = 80 flags S/SA divert-to 127.0.0.1 port 3129) Squid debugging output shows nothing, as I mentioned - no attempted connection, no activity of any kind, although the startup sequence does show "Accepting TPROXY intercepted HTTP Socket connections at local=127.0.0.1:3129 remote=[::] FD 9 flags=25", which would appear to indicate that it IS listening on port 3129, which is what PF is (supposedly) diverting to. Using rdr-to in pf, at least I saw the attempted connection in squid, and got a return page from squid, although it never let anything through (perhaps due to the redirection loop?). So to summarize, at this point I have added the following three lines to pf.conf (my inside network is 192.168.10.0/24, and the interface IP on the inside NIC is 192.168.10.1): match out on $outsideIF from !(outsideIF:network) nat-to $OutsideIP pass in quick inet proto tcp from 192.168.10.0/24 to port www divert-to 127.0.0.1 port 3129 pass out quick inet from 192.168.10.0/24 divert-reply And my squid.conf contains the following: acl authorized_hosts dstdomain .google.com acl authorized_hosts dstdomain .wunderground.com acl authorized_hosts dstdomain .noaa.gov http_access allow authorized_hosts http_access deny to_localhost http_access deny all http_port 3129 tproxy http_port 3128 coredump_dir /var/squid/cache refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 deny_info http://192.168.10.1/login.py all Although as I said it doesn't appear to me that squid is getting the traffic at all. When running squid in debug mode, I see the following: # squid -d8 -N 2014/07/25 08:10:58| Set Current Directory to /var/squid/cache 2014/07/25 08:10:58| Starting Squid Cache version 3.4.2 for i386-unknown-openbsd5.5... 2014/07/25 08:10:58| Process ID 28065 2014/07/25 08:10:58| Process Roles: master worker 2014/07/25 08:10:58| With 128 file descriptors available 2014/07/25 08:10:58| Initializing IP Cache... 2014/07/25 08:10:58| DNS Socket created at [::], FD 5 2014/07/25 08:10:58| DNS Socket created at 0.0.0.0, FD 6 2014/07/25 08:10:58| Adding nameserver 8.8.8.8 from /etc/resolv.conf 2014/07/25 08:10:58| Adding nameserver 8.8.4.4 from /etc/resolv.conf 2014/07/25 08:10:58| Logfile: opening log daemon:/var/squid/logs/access.log 2014/07/25 08:10:58| Logfile Daemon: opening log /var/squid/logs/access.log 2014/07/25 08:10:58| Store logging disabled 2014/07/25 08:10:58| Swap maxSize 0 + 262144 KB, estimated 20164 objects 2014/07/25 08:10:58| Target number of buckets: 1008 2014/07/25 08:10:58| Using 8192 Store buckets 2014/07/25 08:10:58| Max Mem size: 262144 KB 2014/07/25 08:10:58| Max Swap size: 0 KB 2014/07/25 08:10:58| Using Least Load store dir selection 2014/07/25 08:10:58| Set Current Directory to /var/squid/cache 2014/07/25 08:10:58| Finished loading MIME types and icons. 2014/07/25 08:10:58| HTCP Disabled. 2014/07/25 08:10:58| Adaptation support is off. 2014/07/25 08:10:58| Accepting TPROXY intercepted HTTP Socket connections at local=[::]:3129 remote=[::] FD 9 flags=25 2014/07/25 08:10:58| Accepting TPROXY intercepted HTTP Socket connections at local=0.0.0.0:3129 remote=[::] FD 10 flags=25 2014/07/25 08:10:58| Accepting HTTP Socket connections at local=[::]:3128 remote=[::] FD 11 flags=9 2014/07/25 08:10:58| Accepting HTTP Socket connections at local=0.0.0.0:3128 remote=[::] FD 12 flags=9 2014/07/25 08:10:59| storeLateRelease: released 0 objects And that's all she wrote, even when attempting access through the box. Note that the https:// protocol does still work, since I am not attempting to send that through squid (yet at any rate). One final note: it looks to me as though squid is doing something with ipv6. While this shouldn't be a problem, we do not have ipv6 anywhere in our network, nor will we ever, so it would make me feel better if I could just turn that off completely. Thanks for any help/suggestions. ----------------------------------------------- Israel Brewster Systems Analyst II Ravn Alaska 5245 Airport Industrial Rd Fairbanks, AK 99709 (907) 450-7293 -----------------------------------------------
