On 23/07/25 00:48, MAB IT System wrote:
Hello everyone,
I am currently deploying Squid 3.5.12 on Ubuntu Xenial for URL filtering
over multiple VLANs using WCCP.
Please consider an upgrade. That versino of Squid has been out of
support for many years now, and even your Ubuntu Xenial is nearing the
end of their LTS.
*Context:*
*
HTTP traffic is successfully redirected from my Cisco router to
Squid via WCCP (Service 0).
*
HTTPS traffic is redirected via WCCP (Service 70), GRE tunnel works,
redirection appears fine on the router side.
FWIW, I'm not sure if they need different services. WCCP is just a way
to automatically manage routing of traffic towards Squid. Since both
ports are going to the same proxy in theory they should just be diverted
the same way.
*
On my Squid box, iptables properly redirects:
o
TCP 80 → 3127 (intercept)
o
TCP 443 → 3128 (ssl-bump)
That should be "intercept ssl-bump" for NAT intercept + TLS handling
Please consider a different port than 3128 for the HTTPS traffic
interception. It is a well-known port for Squid and has known malware
attacks against broken intercept configurations.
*Problem:*
*
HTTP filtering works perfectly via WCCP.
*
HTTPS connections show *no traffic hitting Squid's 3128 port*
(confirmed via |access.log| and |ss -tulnp|).
*
Yet WCCP router counters show packets being redirected for HTTPS.
Are they making it out of the GRE tunnel so iptables can do its NAT thing?
*
If I manually configure the proxy on a browser, both HTTP and HTTPS
are filtered correctly.
That indicates that you are missing the required iptables mangle table
rules to prevent direct connections from clients to your NAT intercept
ports. That is a major security vulnerability (CVE-2009-0801).
*
If I disable ssl-bump and WCCP for HTTPS, normal navigation resumes.
*iptables NAT rules:*
REDIRECT tcp -- gre1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 redir ports 3127
REDIRECT tcp -- gre1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 redir ports 3128
This is not iptables interface syntax, looks like a management tool.
What do these columns mean?
You also seem to be missing MASQUERADE rules to handle the return
packets SYN+ACK etc. This makes it odd that HTTP was working.
Squid config (extract):
http_port 3127 intercept
http_port 3128 ssl-bump cert=/etc/squid/ssl_sert/myCA.pem key=/etc/
squid/ssl_sert/ca-key.pem generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB
sslcrtd_program /usr/libexec/ssl_crtd -s /var/lib/ssl_db -M 4MB
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump bump all
FYI, bump at step2 is quite dangerous. Prefer doing peek-stare-bump for
the relevant steps 1-2-3. With a whitelist doing splice at step 2 or 3
for things that you find cannot be bumped.
acl whitelist ssl_server_name ...
acl step1 at_step SslBump1
acl step2 at_step SslBump2
ssl_bump peek step1
ssl_bump splice whitelist
ssl_bump stare step2
ssl_bump bump all
*Questions:*
1.
Why does HTTPS via WCCP not reach Squid 3128 (ssl-bump) while HTTP
works fine?
Insufficient details. You will have to do packet traces of what is going
to through the GRE interface to answer that.
2.
Is my WCCP setup wrong for HTTPS? I use service ID 70 with
destination port 443.
See above. If WCCP is sending the port 443 packets through GRE it is
fine. If not, then something is broken there.
Though from what you said it seems like the packets are going missing
somewhere before/after the GRE tunnel.
3.
Could the lack of DNS resolution or browser certificate trust cause
the traffic not to appear at all in Squid logs?
No. In these cases, Squid would still receive the traffic and log errors.
4.
Am I missing something obvious between the router WCCP and Squid’s
ssl-bump setup?
AFAICS the obvious config issues (mentioned above) would not cause
missing packets.
HTH
Amos
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
