Currently, my IPtable indiscriminately sends all incoming request to my Squid transparent proxy. However, since I need SSL to work, I need a way to avoid intercepting SSL traffic.


  1. example.com -> IP=
  2. http access to example.com -> Send to Squid proxy
  3. https access to example.com -> Intercept request for; instead of sending it to Squid proxy, redirect it back to the ip of example.com

Is it possible to do this in iptable? Thanks!

Edit: I'm adding more information about my setup.

  1. End-Client
  2. DNS Server
  3. Squid Box

Due to specific requirement, I have to send traffic to the Squid transparent proxy using DNS redirection rather than typical router/gateway redirection.

Interception Method

  • User Requests www.example.com
  • DNS server points www.example.com to Squid Server
  • Squid server intercepts www.example.com request

Current IP Table Rules

  • Forward Port 80 to Port 3128 (Squid port)
  • Forward Port 443 to Port 3128 (Squid Port)

Apparently, you are using a typical router/gateway to forward traffic to Squid, you can just forward port 80 and ignore 443 because 443 traffic will go directly, bypassing Squid.

Unfortunately, with my current setup, if I don't forward 443, any https connection will simply timeout.

The only solution now is to intercept all 443 request, map the each domain with each unique IP address, and send the request back to the original source IP.

I tried using Rinetd to forward 443 to the original website's IP address. Unfortunately, this method will forward all my 443 traffic to only 1 IP address because it won't differentiate the request IP.

For example, I map 443 to the IP of Gmail.com. When I visit https://gmail.com, it will work fine. However, if I visit https://hotmail.com, it will still send me to the IP of gmail.com

I need to find a way to map each IP with each domain so when I visit gmail.com, it will forward to the IP of gmail; when I visit hotmail.com, it will forward me to the IP of hotmail.com

  • 2
    You might want to share a snippet of your actual rules in place. – user48838 Jul 24 '11 at 4:07
  • There's no such thing as a "transparent proxy with DNS redirection" -- that's just a proxy. – womble Jul 24 '11 at 5:54
  • It's a proxy. It's a transparent proxy, and I use DNS redirection to direct my traffic to my Squid box. I don't know why you down-voted this question? I've provided extensive information. I also spoke to Amos, one of the lead developers of Squid. He pointed me this possible solution so I need some helps on how to achieve this on iptable/rinetd. – Nicolo Jul 24 '11 at 6:09
  • What magical DNS server are you using that does this? Is it saving the requests anywhere? – Zoredache Jul 24 '11 at 7:10
  • @Zoredache: It doesn't take much to make any authoritative DNS server do this – just remove the root hints and add a wildcard A record at the root. – fission Jul 24 '11 at 7:32

What you're describing is a "transparent SSL proxy", which effectively doesn't exist (for the forward case; it could work for SSL accelerators). Let's see why:

  1. The client attempts to resolve serverfault.com.
  2. Your "fictitious DNS" server returns the address of the Squid box.
  3. The client connects to squidbox:443 and attempts to start a TLS session.
  4. At this point, certificates need to be exchanged, etc.

    However…how does the Squid box know what site is really being accessed (ie what remote host to connect to)? The client doesn't tell the SSL server what site it's expecting – it relies on the server to know that already! This is part of the security features of SSL.

It's the same problem with iptables – how would it know what host the client really wanted? That information is simply not available (because the "fictitious DNS" server has thrown it away).

The only way I know to proxy SSL is via the CONNECT method; and for that, you need to specify the Squid box as an explicit proxy.

Honestly, the problem is the DNS redirect. I'm baffled about why you can't use iptables to redirect port 80 and leave 443 alone.

  • Thanks Fission. Based on what you said, Forward proxy could work with SSL? I can sign my own certificate under transparent mode but the browser obviously throws a SSL warning. Would forward mode also do this? – Nicolo Jul 24 '11 at 8:37
  • To answer your last part about leaving 443 alone, if I do not redirect 443 to my Squid port, all https connection will timeout because my squid traffic comes from DNS redirection instead of a typical internal network. My deployment requirement is special challenge. – Nicolo Jul 24 '11 at 8:39
  • I said that it was impossible. Squid cannot simply guess which site you're really trying to connect to. – fission Jul 24 '11 at 8:50
  • You are right about "how does the host know what the client wanted". I couldn't really figure this out either. – Nicolo Jul 24 '11 at 8:51
  • what aspect are you referring as impossible? the SSL part or the general DNS-Redirection-Squid part? For the latter, it works perfectly fine. DNS redirects the http request to my Squid box, my Squid Box intercepts it, proxy it, and acts as the intermediary between the client and the external web servers. This setup is working 100% in my present deployment. The only thing I need is to "enable" the SSL functionality. – Nicolo Jul 24 '11 at 8:55

You can not redirect the https traffic (443) to any port, using iptables. Squid does not process https requests in transparent mode (only http):

PD: eth1 localnet and eth0 internet

You can do this: Redirect http traffic LAN (eth1) to a squid proxy transparent-port 8080 (http). In squid.conf must be the rule: http_port 8080 intercept

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 8080

And open 443 port to localnet

iptables -A INPUT -i eth1 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i eth1 -p tcp --dport 443 -o eth0 -j ACCEPT

You can not do this: Redirect https traffic LAN (eth1) to a squid proxy non-transparent-port 3128 (https) (Fake Rule). It does not matter if in squid.conf the rule exists: http_port 3128

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j REDIRECT --to-port 3128


  1. Squid-in-the-middle SSL Bump
  2. Use a filtering by DNS instead of Proxy (like pi-hole). But it's slower than squid and it does not filter the protocol DNS over HTTPS

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.