PF and Squid 4.6 in intercept mode on OpenBSD 6.5

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

PF and Squid 4.6 in intercept mode on OpenBSD 6.5

Mazandar Wiki
I'm trying to run Squid 4.6 in the intercept mode on OpenBSD 6.5. I've installed Squid with pkg_add(1), so it is complied with --disable-pf-transparent and --enable-ipfw-transparent (which seems to be OK according to various sources).

I've these lines in /etc/squid/squid.conf

http_port 192.168.1.100:3127 intercept

and /var/squid/log/cache.log reports:

Accepting NAT intercepted HTTP Socket connections at local=192.168.1.100:3127 remote=[::] FD 14 flags=41

I've two network interfaces, both of them are in the same subnet, the first is assigned an IP address of 192.168.1.105, and the second one is assigned 192.168.1.100 (on which squid listens to the requests).

I want to divert all my own web traffics to the squid (my goal is just to have a simple and local web caching mechanism on my laptop). This is /etc/pf.conf:

srcaddr = "192.168.1.105"
squid = "192.168.1.100"

block return    # block stateless traffic
block return in on ! lo0 proto tcp to port 6000:6010
block return out log proto {tcp udp} user _pbuild

block all

pass inet proto {tcp, udp} to port domain
pass inet proto icmp

pass inet proto tcp from {127.0.0.1, $srcaddr} to port {80 443} \
        divert-to $squid port 3127

pass inet proto tcp from 192.168.1.100 to port 80

However, it doesn't work. Actually no traffic is diverted to squid and packets are sent out unchanged to the network through $srcaddr, as reported by pflog. Web pages are fully accessible, however, they are not passed through squid (access.log doesn't report anything).

Could you please tell me what's wrong with this configuration?
Reply | Threaded
Open this post in threaded view
|

Re: PF and Squid 4.6 in intercept mode on OpenBSD 6.5

Evaldas Auryla
Hi, maybe tell squid to listen on localhost and then your browser to use proxy on localhost:3128, simpler ?

As for PF divert-to, it worked for me with “divert-to localhost”.

Best regards,
Evaldas

On 17 May 2019, at 15:46, Mazandar Wiki <[hidden email]> wrote:

I'm trying to run Squid 4.6 in the intercept mode on OpenBSD 6.5. I've installed Squid with pkg_add(1), so it is complied with --disable-pf-transparent and --enable-ipfw-transparent (which seems to be OK according to various sources).

I've these lines in /etc/squid/squid.conf

http_port 192.168.1.100:3127 intercept

and /var/squid/log/cache.log reports:

Accepting NAT intercepted HTTP Socket connections at local=192.168.1.100:3127 remote=[::] FD 14 flags=41

I've two network interfaces, both of them are in the same subnet, the first is assigned an IP address of 192.168.1.105, and the second one is assigned 192.168.1.100 (on which squid listens to the requests).

I want to divert all my own web traffics to the squid (my goal is just to have a simple and local web caching mechanism on my laptop). This is /etc/pf.conf:

srcaddr = "192.168.1.105"
squid = "192.168.1.100"

block return    # block stateless traffic
block return in on ! lo0 proto tcp to port 6000:6010
block return out log proto {tcp udp} user _pbuild

block all

pass inet proto {tcp, udp} to port domain
pass inet proto icmp

pass inet proto tcp from {127.0.0.1, $srcaddr} to port {80 443} \
        divert-to $squid port 3127

pass inet proto tcp from 192.168.1.100 to port 80

However, it doesn't work. Actually no traffic is diverted to squid and packets are sent out unchanged to the network through $srcaddr, as reported by pflog. Web pages are fully accessible, however, they are not passed through squid (access.log doesn't report anything).

Could you please tell me what's wrong with this configuration?

Reply | Threaded
Open this post in threaded view
|

Re: PF and Squid 4.6 in intercept mode on OpenBSD 6.5

Stuart Henderson
On 2019/05/17 14:42, evaldas wrote:
> Hi, maybe tell squid to listen on localhost and then your browser to use proxy on
> localhost:3128, simpler ?

this may be the only way .. (command-line software often honours
environment variables for this which you can set in your profile or
login.conf).

> As for PF divert-to, it worked for me with “divert-to localhost”.

divert-to isn't for outbound packets.

>
>
>     On 17 May 2019, at 15:46, Mazandar Wiki <[hidden email]> wrote:
>
>     I'm trying to run Squid 4.6 in the intercept mode on OpenBSD 6.5. I've installed Squid with
>     pkg_add(1), so it is complied with --disable-pf-transparent and --enable-ipfw-transparent
>     (which seems to be OK according to various sources).
>
>     I've these lines in /etc/squid/squid.conf
>
>     http_port 192.168.1.100:3128
>     http_port 192.168.1.100:3127 intercept
>
>     and /var/squid/log/cache.log reports:
>
>     Accepting NAT intercepted HTTP Socket connections at local=192.168.1.100:3127 remote=[::]
>     FD 14 flags=41
>
>     I've two network interfaces, both of them are in the same subnet, the first is assigned an
>     IP address of 192.168.1.105, and the second one is assigned 192.168.1.100 (on which squid
>     listens to the requests).
>
>     I want to divert all my own web traffics to the squid (my goal is just to have a simple and
>     local web caching mechanism on my laptop). This is /etc/pf.conf:
>
>     srcaddr = "192.168.1.105"
>     squid = "192.168.1.100"
>
>     block return    # block stateless traffic
>     block return in on ! lo0 proto tcp to port 6000:6010
>     block return out log proto {tcp udp} user _pbuild
>
>     block all
>
>     pass inet proto {tcp, udp} to port domain
>     pass inet proto icmp
>
>     pass inet proto tcp from {127.0.0.1, $srcaddr} to port {80 443} \
>             divert-to $squid port 3127
>
>     pass inet proto tcp from 192.168.1.100 to port 80
>
>     However, it doesn't work. Actually no traffic is diverted to squid and packets are sent out
>     unchanged to the network through $srcaddr, as reported by pflog. Web pages are fully
>     accessible, however, they are not passed through squid (access.log doesn't report
>     anything).
>
>     Could you please tell me what's wrong with this configuration?
>
>

Two network interfaces on the same subnet is unlikely to do what you expect.