All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aleksandar Milivojevic <amilivojevic@pbl.ca>
To: netfilter@lists.netfilter.org
Subject: Re: Transparent Remote Proxy Server
Date: Mon, 27 Sep 2004 14:30:02 -0500	[thread overview]
Message-ID: <41586A3A.5060901@pbl.ca> (raw)
In-Reply-To: <9B51275E-10B2-11D9-9099-0003931DA24A@freezone.co.uk>

ms419@freezone.co.uk wrote:
> Thank you sincerely for your suggestion! You are correct: It is simpler 
> to use DNAT & MASQUERADE. I tried it & it works. But now, I am trying to 
> avoid using NAT.
> 
> The problem with NAT (as I understand it) is it rewrites the destination 
> address, which breaks HTTP/1.0 requests without a Host: header. By using 
> policy routing, I hope to route traffic through wum without rewriting 
> the destination address.
> 
> I'm using as my guide the Transparent Proxy HOWTO by Daniel Kiracofe.

As Jason wrote, REDIRECT will also rewrite destination IP address. 
Squid is using woodoo magic to find out what was the original 
destination address before rewriting (that's why you need to also change 
Squid configuration).  Squid can do that only if it runs on the same box 
where the address was rewritten.  Even the woodoo magic has limitations ;-)

Daniel's document is using nat table for both filtering and NATing, 
which is the approach I don't particulary like.  Plus the rules are very 
open (made to demonstrate the concept, not to be used on a real firewall).

Anyhow, what you might try out is a bit of debugging to see what is 
going on the wire.  Your tcpdump from wum shows that it got SYN packet, 
and that it sent out SYN ACK.  I don't see third packet with ACK going 
back to wum, so it might be that it got dropped somewhere.  My next step 
would be to move to tor.  I'd guess if you run tcpdump on tor's 
interface to internal network, you'd see only SYN packet, and not SYN 
ACK.  And if you run it on interface wheer wum is connected that you 
would see both SYN and SYN ACK.  If that is the case, than you might 
have something else on tor that is causing it to drop return packets 
from wum.  As usual, without having an insight into your entire rule 
set, it might be hard to tell why (something like output of iptables-save).

-- 
Aleksandar Milivojevic <amilivojevic@pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7


  parent reply	other threads:[~2004-09-27 19:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-23 21:27 Transparent Remote Proxy Server ms419
2004-09-24 19:01 ` Aleksandar Milivojevic
2004-09-27 18:25   ` ms419
2004-09-27 18:27     ` Jason Opperisano
2004-09-27 19:30     ` Aleksandar Milivojevic [this message]
2004-09-27 19:37       ` Jason Opperisano
2004-09-28  6:38         ` Arthur Meyer
2004-09-28 13:44         ` Jason Opperisano
2004-10-01 22:53           ` FIXED: " ms419

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41586A3A.5060901@pbl.ca \
    --to=amilivojevic@pbl.ca \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.