If I understand you correctly, what you want to do isn't going to be handled simply by configuring iptables. The REDIR target can only be used to target processes running on the local system. I believe attempting to use a DNAT target to forward the to the remote squid box would remove some of the information the remote squid box needs to properly handle the request
If you allow me to guess a bit. I think you are trying to leave the default gateway as 192.168.1.1 on your host and then send your port 80 traffic across the vpn right?
The remote squid needs some configuration so that it can actually act as a transparent proxy. If you can setup the correct iptables redirection on the squid host, and the remote host is in the network path, then it is possible to do use some advanced routing to forward all port 80 requests across the vpn.
P.S. If I am understanding your needs correctly add a comment, I can update my answer with more details about how to setup routing.
The difference is between server-first and client-first is what error message the user ends up seeing (or not seeing)
With client-first SSL bump, there's three problems:
- The SSL certificate presented mismatches the destination; e.g. The client sees that the SSL certificate is issued to proxy.yourdomain.com, but the user is trying to visit www.securewebsite.com. Their browser will warn them about this. (bad)
- The SSL certificate is from an untrusted certificate authority. Their browser will warn them about this too. (bad)
- If there's a problem with the server SSL certificate, there's no good way to let the client know. By the time Squid finds out there's an error (maybe it's expired, not trustworthy, for the wrong site, etc.) the client already has a "good" SSL certificate and thinks it's about to receive the real traffic. Their browser can't warn them about this. (also bad)
Server-first SSL bump eliminates the first and third problems. The second remains. Here's a decent resource on the reasoning for using server-first ssl bumping. It was apparently written when the feature was still being developed, so don't let the future tense confuse you.
Since you generated the certificate yourself, and anyone can generate a certificate themselves, merely having a certificate doesn't mean the communication is safe. The certificate has to be from an issuer you trust. Browsers come by default with a list of trusted certificate authorities. Those CAs vouch for the certificates they sell, and that's how your computer knows to trust certificates.
The solution to this problem is that you have to tell your computer to trust the certificate you're using for ssl-bumping. The procedure is different for different OSes. For windows clients you can push something out via GPO, for mobile you can push it out with MDM, etc.
Just for testing (in windows), you can right click the certificate and choose install. Walk through the wizard. Instead of letting windows choose where to put the certificate, browse and select Trusted Root Certification Authorities. Once you've done this, your computer will trust any certificate generated by your squid ssl-bump server.
Best Answer
You can do that by setting up iptables to forward traffic to the squid box:
http://tldp.org/HOWTO/TransparentProxy-6.html
Google for 'transparent proxy squid' if you need more examples.