How to Use Iptables in Linux to Forward Http and Https Traffic to a Transparent Proxy

How to use iptables in linux to forward http and https traffic to a transparent proxy

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 9090

HTTPS cannot be used with a transparent proxy. There are some hacks, but it doesn't make any sense and is useless.

Privoxy does not work with traffic from iptables

I'm not entirely familiar with how Privoxy works, however I do know how intercepting proxy works on Linux.

HTTP proxies and intercepting proxies work in very different ways. An HTTP proxy get the destination from the first line of the query, which would contain the domain name (e.g. it should be GET http://www.google.com/ HTTP/1.1). For HTTPS, it does an HTTP CONNECT request with the domain:port to connect to (e.g. CONNECT www.google.com:443 HTTP/1.1).

An intercepting proxy get the original destination address from the kernel by doing a getsockopt() with some specific parameters. It has no knowledge of higher level protocol.

In general redirecting with iptables a request to an HTTP proxy does not work because of theses differences. That said, Privoxy seems to have a configuration option accept-intercepted-requests that you can use so it read the target from the Host: HTTP header. With that configuration, it should be able to handle HTTP requests redirected using iptables. As the documentation says, this is not supported for HTTPS. You will need to use some additional software which can do the forwarding to an HTTP proxy, probably much like Proxifier does. I know moproxy can do that. It ought to not be the only one, but I don't know others.

Additional questions:

• Why setting the variables works, and through iptables doesn't?

because HTTP and transparent/intercepting proxy works in different ways. When the variables are present, curl (and other) alter how they send the query, but with iptables, they don't (as they don't know you use a proxy).

• Why do I have to set the https_proxy to point to http://...? Is that privoxy-related?

the http:// in your environment variable is to describe how you connect to the proxy (it could actually be https:// if your proxy had a tls certificate, and it would work with http requests too, though they would be encrypted only from you to the proxy, not from the proxy to the remote server).

• Regarding the comment "HTTPS is not supposed to be used with transparent proxies": So how does Proxifier work on Windows? If that is not transparent a proxy, is there another term for it? Why can't we have something similar on WSL/Linux?

I don't know the specifics of how transparent proxies work on Windows. Assuming it works a lot like Linux, Proxifier probably redirect the request to a local port, get the actual destination, wrap the data in a way it's understood by HTTP/SOCKS proxy and send that to the proxy you told it to use. Maybe the capture part is a bit different (creating a new network interface, ask Windows to send the traffic their, reconstruct the stream from raw tcp packets, wrap the data). This is often called transparent proxy as the client doesn't know a proxy is used, some call it an intercepting proxy instead. And we can have something similar, moproxy is an example (probably not the only one)

Iptables redirect to remote squid proxy

As far as I understand your question, the traffic is generated locally. Thus, packets won't traverse the PREROUTING chain.
You have to work on OUTPUT or POSTROUTING :

iptables -t nat -A OUTPUT -p tcp -o lo --dport 80 -j DNAT --to publicip:3128

Also, be sure to set-up your Squid in transparent proxying mode :

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

If it's still not working, pleas provide additional details on what is not working (tcpdump traces, squid logs).

Squid+iptables: how do i allow https to pass-through and bypassing Squid?

After actually considering chewing through my own wrists and dreaming of IPs all night long + brute force googling/trying ANYTHING i could get my digital fingers on i managed to put something together that actually works. I dont know the technical reasons why, so if you can provide set explanations please do so! :D

PS: everything in the explanation is done via command line

PS: this is not a final solution, but its a working one in answer to my own question.

Here it is:

Step 1: Had to enable IP Forwarding on the box:

vim /etc/sysctl.conf

//find and uncomment the following

net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=1

Step 2: Add loop back rule (this is more for when all ports are covered, apparently many apps need it?

iptables -I INPUT -i lo -j ACCEPT

Step 3. Add rules for the bypassing of port 443: (eth1 is internet interface and x.x.x.x/eth0 is LAN interface)

iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -t filter -A FORWARD -i eth0 -p tcp --dport 443 -j ACCEPT

iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source x.x.x.x

Step 4. Then finally the rules making Squid transparent:(x.x.x.x is IP of LAN interface)

iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j DNAT --to-destination x.x.x.x:3128

iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128

Will routing traffic to proxy break SSL?

To access a SOCKS server each TCP connection must be prefixed with the necessary SOCKS header. That means, that a simple redirect is not possible. You need instead a protocol converter like redsocks or transocks (never used these, but from the description they do what you need).

Apart from that it is not a problem to simply redirect HTTPS traffic or use these protocol converters, as long as you don't change the SSL stream itself. The only problem is if transparent proxies try to intercept and re-route this traffic to other sites (like redirecting to a capture portal) or try to decrypt the connection in order to analyse it (like in firewalls). These kind of interceptions will be noticed from the browser, because either the name in the certificate does not match the target name and/or the issuer of the certificate is not trusted.

---

Related Topics