I think your problem is the NAT table rules. You are missing some
critical exceptions to let squid make the outbound tunnels.
On 17/10/23 07:51, Bud Miljkovic wrote:
Let me try one more time.
Here is my system configuration:
{HW-Box} --> Local Server{ (eth0[port 444]) -----+
|
+-----------------------------------------------------+
|
|
+-----> ([3129] Transparent Squid proxy) ---> (eth1[port443])
}--+
|
+------------------------------------------------------- ---+
|
+->--{ INTERNET Server }
The setup and the problem:
- The HW box tries to establish an HTTPS transparent connection with
a server located within Internet.
Drop the word "transparent" from this thinking. It is a connection.
- It uses the Local Server and send its request via eth0 interface.
- The request is Pre-routed from eth0, port 443, to the Transparent
Squid proxy (v3.5.25), listening at port 3129.
Correction. NAT'ed, not "routed". The distinction is important and
impacts which type of configuration will work and which will guarantee
errors.
* NAT is only working when performed on the machine running Squid.
* "routed" can be done from a remote machine to the Squid machine. But
does need additional NAT or TPROXY on the Squid machine.
- For testing purposes, the Squid proxy is configured to pass only
the HTTPS traffic transparently via the eth1 interface, using sing the
`tcp_outgoing_address <ip_addr>` directive. Please see the
squid-ota.conf file content below.
To be clear FTR; Squid *cannot* guarantee a particular interface. Only
the OS can decide that.
Your Squid is setting the TCP src-IP on outbound packets as a *Hint*
(albeit a strong one) for the OS to use in its routing choices.
- While testing, I am monitoring the eth1 output via tcpdump and I
get the following:
# tcpdump -i eth1 port 443 -n -X -q -w tcp_dump_24
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture
size 262144 bytes
0 packets captured
1 packet received by filter
0 packets dropped by kernel
3 packets dropped by interface
- But nothing is detected!?
Nod.
FWIW, I have had mixed success with tcpdump when NAT and MASQUERADE are
happening on the machine. It plugs in at the lowest layer somewhere
around the point packets are actually going to/from the network. So
packets with internal temporary values in them may not show up in the dump.
When NAT, MASQUERADE and routing are manipulating things the iptables
packet counters seem to be a lot more reliable indicator of what traffic
is (not) going through, even if the dump shows less than expected.
- From the above it appears that there is no eth1 output at port 443?
Possibly. Maybe.
I have included the printouts of the `iptables -nvL` and `iptables -nvL
-t nat` commands.
Can someone tell me what I have done wrong here and perhaps suggest a
solution?
Cheers,
Bud
=========================
Squid configuration file:
# 1) Visible hostname
visible_hostname ctct-r2
# 2) Initialize SSL database first
sslcrtd_program /usr/libexec/ssl_crtd -s /var/lib/ssl_db -M 4MB
# 3) Listen to incoming HTTP traffic
http_port 3128
# 4) Block all HTTP traffic
http_access deny all
Ah, This will block the CONNECT tunnels.
"CONNECT" is an HTTP request method. This (4) rule will both reject the
CONNECT tunnel being handled, and/or will prevent the "splice" action
from being allowed to pass it through Squid in its form as a "CONNECT"
message.
Please keep the basic security rules (http_access deny ...) provided in
the default squid.conf for your version. You can see them at
<https://wiki.squid-cache.org/Releases/Squid-3.5#squid-35-default-config>
The rules you have for your local policy should go after the line
"INSERT YOUR OWN RULE(S) HERE".
You may remove the existing "http_access allow ..." lines as needed if
you do not want them to happen.
# 5) Listen for incoming HTTPS traffic and intercept it
https_port 3129 intercept ssl-bump cert=/etc/squid/ssl_cert/myCA.pem
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
# 6) Pass the SSL (HTTPS) traffic trasparently throught
ssl_bump splice all
# Do not use caching
# cache_dir ufs /var/volatile/log/squid/logs 100 16 256
# 7) Send out all HTTPS traffic to destination server via given IP address
tcp_outgoing_address 10.3.19.92
Again this is not limited to one protocol (HTTPS). **All** TCP outgoing
packets from your Squid will use this regardless of their protocol.
=====================================================
iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 1234K packets, 306M bytes)
pkts bytes target prot opt in out source
destination
96 5760 REDIRECT tcp -- eth0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:443 redir ports 3129
13943 837K REDIRECT tcp -- eth0 * 0.0.0.0/0
0.0.0.0/0 tcp dpt:80 redir ports 3128
Per <https://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect>
This table should contain an ACCEPT for Squid outbound connections
before the REDIRECT. Like so:
iptables -t nat -A PREROUTING -s $SQUIDIP -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -s $SQUIDIP -p tcp --dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT ...
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT ...
You do not list the "mangle" table. But check that you have the rule
there protecting the port as well:
iptables -t mangle -A PREROUTING -p tcp --dport $SQUIDPORT -j DROP
HTH
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
