Messages

Hi all,

I would like to be able to "double" the access logs whenever possible:

1 - per Syslog facility and further sent to remote log aggregation.
2 - per File (/var/log/squid/access.log) to crawl the logs with SARG locally.

Perhaps I could do the point #2 using syslog datas but I wouldn't know "how" just yet.
If anyone could give some hints, thanks a lot.

Let me know,
Kind regards,
m.

Had the same issue, here is what fixed it for me:

• updated the vCPU scheme of the VM from "kvm64" to "Haswell-noTSX".
• VM power off/power on.
• shifted the IPS engine from "Aho–Corasick Ken Steele variant" to "Hyperscan" (only possible post point #1 here).

According to the docs, Hpyerscan seems to be the best options whenever supported, I'll leave it at that here.
https://docs.opnsense.org/manual/ips.html

Kind regards,
m.

Hi team,

Has anyone already implemented this Squid feature on OPNsense?
https://wiki.squid-cache.org/ConfigExamples/Portal/Splash

Roughly, this would use a "squid.conf" directive to present a "captive portal" web based authentication form for example.
using directive like:

Code Select Expand

deny_info 511:/etc/squid/splash.html session_is_activeI have to reckon that I haven't completely understood that Squid feature yet and what is needed behind it (backend auths, session state, time management etc..)

I was wondering if perhaps something like this could be implemented jointly with the OPNsense Captive Portal facility in fact, this in Explicit Proxy use cases.

Let me know,
Kind regards,
m.

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.

Found a plausible explanation / need to test without SSL Bump'in :

https://stackoverflow.com/questions/45084436/squid3-proxy-server-ssl-bump-blocking-web-socket-connections

----
Squid doesn't support websocket natively, only through CONNECT tunnel, which your client has to be aware of -- which it won't be if you are MITMing connections.
----

EDIT: just tested, without SSL Bump, WebSocket is working all fine..

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.

Hi there all,

I have a simple explicit proxy setup in which I didn't exclude (yet) a Guacamole host used for Remote Access (internal/external).
While connecting to that system through the OPNsense/Squid setup, I could log on with no issue although any Remote Access connection wouldn't work.
These are WebSocket based, is this possible through Squid? Have I missed some config options?

I have for now updated my wpad.dat with a DIRECT directive to that host and all is fine, just more for my knowledge.

Let me know,
Kind regards,
m.

Thanks a lot -- I'll take that as my best practice around that:

----
Domain Overrides are now considered deprecated, you should only use Query Forwarding / DNS over TLS for new setups. That's actually documented, but I agree that a hint in the UI wouldn't hurt. Changing the name to "Domain Overrides (legacy)" might be sufficient. Thoughts?
----

Cheers,
m.

Hi there all,

I'm here using Unbound DNS on OPNSense and I'd have a few questions about it.

• what is the difference(s) between Domain Overrides AND Query Forwarding?
• if using one or the other (Overrides OR Query Forwarding) is there a possibility to log where each queries are sent?

My goal is simple, forward a few domains onto internal servers while carrying the rest over DoT although I'd want to assess that internally geared resolutions aren't attempted toward the DoT setup. And well, tcpdump'ing DoT give some info's but obviously no queries details, which is the DoT purpose ain't it =)

Let me know,
Thanks,
m.

Hi again all,

So after troubleshooting a notch more, it turns out that:

- source port UDP:51820 packets flying out over the overlay only occurs upon peer "disconnection" (when turning WG tunnel OFF on the client device).
- the time frame while this is occuring is always around 900 seconds, I suspect CLOSE_WAIT and TIME_WAIT sessions perhaps.

Thanks for any possible advice here.

Cheers,
m.

Hi all,

I'll try to summarize my setup:

- wg0 instance reachable through the WAN interface + peers + config + unbound DNS etc etc (all working super duper fine)
- ovpnc1 interface where I'm routing wg clients 0.0.0.0/0 type of traffic (working super duper)

My only current concern is that this setup as somewhat of an asymmetrical routing issue, as either WAN or ovpnc1 could reach 0.0.0.0/0 -- I sometimes have witnessed some UDP:51820 source port bound packets to fly out over the overlay/ovpnc1 interface, which is unwanted. I did countermeasure that through the firewall but I'd been hunting for a cleaner solution.

Would it be possible to bound a specific and unique gateway to the WireGuard service itself? Hence always receiving and sending WireGuard tunnel service traffic over the exact same interface/gw combo at the opnsense level.

Let me know,
Regards,
m.

Hi Franco, team,

Clean fix indeed =) I've just seen the 24.1.7 announcement, thanks for all the work.
Quick question: should I revert to the "original" status / edit

Code Select Expand

/usr/local/opnsense/service/templates/OPNsense/Trust/openssl.cnf to it's original status prior to apply 24.1.7 ?

Thanks,
Regards,
m.

Hi Franco, team,

Tested this workaround with prior to that, re-enabling Squid 6.9 on 24.1.6.
All fine here, config parses all good.

Thanks guys!
Cheers,
m.

I think all later 6.x are affected.  Come to think of it it may be an OpenSSL 3 incompatibility...

Hi Franco,

Yes, I've carefully read the github issue and comments and hum well, even with 6.8 it still SEGFAULT's. I'll need to read more about the latest findings; squid's legacy openssl issue.

On another frontline, I'm here running different proxies all running squid 6.8 + ssl bumping all over + a really bigger and rather complex configuration which doesn't show any of such artifacts.. Theses are running on Debian though.

Anyways, let's hope for a fix at some point as I do think that transparent proxy on opnsense is extremely sexy TBH.

Cheers,
m.

Hi Franco, all,

Thanks for the lead =) Here is what I've done to get it back to "work", which is a workaround/downgrade:

Code Select Expand


root@opnsense:/ # opnsense-revert -r 24.1.5 squid
Fetching squid.pkg: ... done
Verifying signature with trusted certificate pkg.opnsense.org.20240105... done
squid-6.8: already unlocked
Installing squid-6.8...
package squid is already installed, forced install
...


This obviously after having passed the OPNsense 24.1.6-amd64 update.

Thanks,
m