Forward to WebSafety/use of ICAP only

[Nicolas Wälti]

Hello all,

I've an issue/question here... I'm trying to use "only" the web filtering capabilities of WebSafety because I want my proxy to be transparent to my kids, so every device gets checked (smartphone, pc, talets...) I currently use opnSense (fork of pfSense) as my router/firewall and it also has a squid Server and it allows for specific ICAP server definition.

What I would like to achieve is either a forward from opnSense squid to WebSafety squid or just use the ICAP of WebSafety, but non of those scenario work.

Also simply forwarding http/https traffic via NAT works with the internal Squid, but not with Websafety... Can someone please point me in the right direction ?

Thanks a million in advance,

Nick

[Rafael Akchurin]

Hello Nicolas,

 

First let the ICAP server to listen on public IP of the web safety proxy box.

Then direct opnsens’s squid to use that as ICAP server (see how we do that for squid on the box itself – UI/Squid/General/Verification).

 

We use this to debug ICAP all the time, so it should work.

 

Best regards,

Rafael

--
You received this message because you are subscribed to the Google Groups "Diladele Web Safety" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-safety+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-safety/fa2943a1-e1de-4690-ab5f-1fc4c48224c7n%40googlegroups.com.

[Nicolas Wälti]

Hi Rafael,

Thanks for the answer... Well, it seems (to me) that the config is done correctly:
This is my WebSafety definition:

WebSafety is running in a docker and its port is opened, this is what I get using a c-icap-client on my debian machine:

And this is the configuration of the ICAP in opnSense:

Do you see something wrong ?

Thanks,

Nicolas

[Rafael Akchurin]

Try issuing a telnet connect to the IP address and port you think the icap server runs – and type something like GET / followed by enter enter

 

If connect fails the icap server is NOT listening on the IP you think.

 

 

From: web-s...@googlegroups.com <web-s...@googlegroups.com> On Behalf Of Nicolas Wälti
Sent: Tuesday, January 18, 2022 3:44 PM
To: Diladele Web Safety <web-s...@googlegroups.com>
Subject: Re: Forward to WebSafety/use of ICAP only

 

Hi Rafael,

 

Thanks for the answer... Well, it seems (to me) that the config is done correctly:
This is my WebSafety definition:

WebSafety is running in a docker and its port is opened, this is what I get using a c-icap-client on my debian machine:

 

And this is the configuration of the ICAP in opnSense:

To view this discussion on the web visit https://groups.google.com/d/msgid/web-safety/4b4e1fc5-b3bf-465e-bd8c-80497c024d67n%40googlegroups.com.

[Nicolas Wälti]

It does answer:

... but both here are empty:

And nothing seems filtered at all...

[Rafael Akchurin]

Good then, if the server is accessible – let see what data it gets (set the Enable dump of ICAP session contents on disk into /opt/websafety/var/temp folder. Should be enabled ONLY by Diladele Web Safety support team! On the network page of the ICAP server), save and restart and see if you have any files in temp folder

 

From: web-s...@googlegroups.com <web-s...@googlegroups.com> On Behalf Of Nicolas Wälti
Sent: Tuesday, January 18, 2022 3:54 PM
To: Diladele Web Safety <web-s...@googlegroups.com>
Subject: Re: Forward to WebSafety/use of ICAP only

 

It does answer:

... but both here are empty:

And nothing seems filtered at all...

On Tuesday, January 18, 2022 at 3:46:26 PM UTC+1 rafael....@diladele.com wrote:

Try issuing a telnet connect to the IP address and port you think the icap server runs – and type something like GET / followed by enter enter

 

If connect fails the icap server is NOT listening on the IP you think.

 

 

From: web-s...@googlegroups.com <web-s...@googlegroups.com> On Behalf Of Nicolas Wälti
Sent: Tuesday, January 18, 2022 3:44 PM
To: Diladele Web Safety <web-s...@googlegroups.com>
Subject: Re: Forward to WebSafety/use of ICAP only

 

Hi Rafael,

 

Thanks for the answer... Well, it seems (to me) that the config is done correctly:
This is my WebSafety definition:

WebSafety is running in a docker and its port is opened, this is what I get using a c-icap-client on my debian machine:

 

And this is the configuration of the ICAP in opnSense:

To view this discussion on the web visit https://groups.google.com/d/msgid/web-safety/b49b039c-b2f1-437e-9427-fe1f0ef6ac40n%40googlegroups.com.

[Nicolas Wälti]

So yes, the folder gets full of guid.#.received and guid.#.sent files, but on the dashboard, ICAP remains without any connections, Traffic Monitor does not shows anything and the "Strict" policy is not applied ?

opnSense squid sents the X-Client-IP header with the correct IP address...

[Rafael Akchurin]

Ok then the ICAP server works as expected, sites which should be blocked are blocked. But Admin UI does not show anything.. I then would presume the Admin UI does not know about ICAP connections because it gets the info by parsing Squid logs – and those are empty because local instance of proxy does not handle any traffic (pfsense does)?

To view this discussion on the web visit https://groups.google.com/d/msgid/web-safety/fc562db1-a26e-4245-84d9-b82380df1b9cn%40googlegroups.com.

[Nicolas Wälti]

Also I've tried to manually add a blocked domain, both in the "Strict" and in the "default" policy, and that one continues to be accessible...

[Nicolas Wälti]

Sites are not blocked..., that's where it get tricky... I can live without logs, but everything is accessible as in "not filtered"

[Rafael Akchurin]

I would first then try to use squid on pfsense as explicit proxy – if blocking occurs normally then the interception *might* be using other not HTTP protocols (like quick, http2, http3)

To view this discussion on the web visit https://groups.google.com/d/msgid/web-safety/ecdabb0f-0c7c-44e2-bebf-bc0a2fc5d256n%40googlegroups.com.

[Nicolas Wälti]

Okay, it seems to work now, there are two caveats to check:

a) I had to disable " Never filter connections to IP addresses within local private LAN (RFC 1918). Default and recommended value is On." since I'm comming from a 172.16.x.x IP.

b) The Strict policy has not been applied as it is not seeing the IP from which I'm comming... Therefore I had to modify the "Default" policy

Thanks a lot for your time ;)

Cheers,

Nick