ZenArmor & Squid / CONNECT requests not triggering ZA

[mokaz]

Hi there folks,

A quick question / setup feasibility check on my side.

I've setup the followings to satisfaction:

• Squid on Loopback only
• ZenArmor in L3 emulated mode

To force a software hop, I've enabled Squid on Loopback only, thus requiring a NAT port forward rule for the Explicit Proxy port (8080) in my example.
Clients would connect through WPAD/wpad.dat with a return "PROXY VTNET0:8080" directive.

You cannot view this attachment.

My concern is that in such a setup, it seems to me that ZenArmor is missing the "vtnet0/LAN" based 8080 CONNECT requests sent towards the Squid Proxy daemon.

Without enabling the WAN interface "vtnet1" in the ZenArmor configuration, Web Controls doesn't catch offending bits/categories.
With the WAN interface enabled, it does, obviously so as Squid would initiate the requested connections through that interface for egress traffic.

I've tested as well using Squid directly bound to the "vtnet0" interface with the same results. I had hoped that perhaps adding a software HOP (loopback) would trigger ZenArmor Web Controls while monitoring the "vtnet0/LAN" interface only. It's not the case.

All in all, it's not a big issue, the real concern is that any offending bits would trigger as being sourced as/from the WAN interface IP, thus rendering analysis a bit more complex in order to find the originating host behind any potential ZA blocks. I'd also vouch that I'd prefer blocking the clients requests rather then the Squid initiated connections.

Is there anything I could do to get full CONNECT requests visibility sent towards the Squid daemon while monitoring the "vtnet0" interface only?
Or have I perhaps missed something obvious?

Let me know,
Thanks a lot,
m.

[sy]

Hi,

Zenarmor should typically capture the traffic on vtnet0 as well. Kindly reach out to the support team using the "Have Feedback" option located in the bottom left corner of the UI and share a pcap file of vtnet0.

[mokaz]

Hi sy,

Thanks for your update, I'll check to do so.
Meanwhile, ZA "does" see the traffic, the issue being that "Web Controls" doesn't pick it up on CONNECT tunnel requests. This while the requested URL's are at disposal in clear text on the LAN side:

Code Select Expand

root@prx1:/home/bobby # tcpdump -i vtnet0 -np | grep CONNECT
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vtnet0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:02:54.074027 IP PROXY-CLIENT.46618 > PROXY-SERVER.8080: Flags [P.], seq 1:257, ack 1, win 502, options [nop,nop,TS val 57998426 ecr 1936303233], length 256: HTTP: CONNECT manyvids.com:443 HTTP/1.1
21:02:54.348588 IP PROXY-CLIENT.46632 > PROXY-SERVER.8080: Flags [P.], seq 1:257, ack 1, win 502, options [nop,nop,TS val 57998701 ecr 1409233581], length 256: HTTP: CONNECT manyvids.com:443 HTTP/1.1
21:04:14.658498 IP PROXY-CLIENT.41590 > PROXY-SERVER.8080: Flags [P.], seq 1:257, ack 1, win 502, options [nop,nop,TS val 58079013 ecr 3706001154], length 256: HTTP: CONNECT manyvids.com:443 HTTP/1.1
21:04:15.019787 IP PROXY-CLIENT.41618 > PROXY-SERVER.8080: Flags [P.], seq 1:257, ack 1, win 502, options [nop,nop,TS val 58079374 ecr 3162541456], length 256: HTTP: CONNECT manyvids.com:443 HTTP/1.1

In the above example, only the Squid initiated "WAN" connectivity request to "manyvids.com" would be caught as "Pornography" (not part of the above tcpdump filter as fired from vtnet1). IMPOV, the CONNECT requests are never matched to any potentially in place filters at all, although they're seen.

I'd say it's an easy use case to reproduce and if needed I could hand you out a PII free OPNsense config XML file, you'd just need to restore it and adapt to your IP schemes and test on your own..

Let me know,
Cheers,
m.

[sy]

Hi @mokaz,

Sharing a screenshot of the session details from Live Sessions - Connections by clicking the magnifying glass icon will suffice.

You can share it using the "Have Feedback" option located in the bottom-left corner of the interface.