Linux Netfilter discussions
 help / color / mirror / Atom feed
From: John Haxby <john.haxby@oracle.com>
To: netfilter@vger.kernel.org
Subject: REDIRECT problem
Date: Thu, 15 Jul 2010 10:34:18 +0100	[thread overview]
Message-ID: <4C3ED61A.4050303@oracle.com> (raw)

Hello All,

For some time now, I've been using REDIRECT (roughly) like this:

$IPT -t nat -A PREROUTING -j proxyt
$IPT -t nat -A proxyt -d <network> -p tcp -m tcp -k RETURN
    (repeated lots of times for different networks)
$IPT -t nat -A proxyt -p tcp -m tcp ! --dport 3128 -j REDIRECT 
--to-ports 3128

That works just fine: TCP connections to any network other than the 
specific get directed to the process listening on port 3128 (which  then 
uses HTTP CONNECT on a proxy to connect to the Big Bad Internet).

I use ebtables on a pair of machines running Xen to redirect traffic to 
this machine:

     +-------------+     +-------------+
     | xen         |     |        xen  |
     |       +---+ |     | +---+       |
     | +---+ | P |=========| P'| +---+ |
     | | A | +-+-+ |     | +---+ | B | |
     | +---+   |   |     |       +---+ |
     |         |   |     |             |
     +---------|---+     +-------------+
               |
        Big Bad Internet


Traffic from A is redirected (by ebtables) to P which has these rules on 
it and that connection is just fine.  Traffic from B is directed to P' 
which then forwards traffic to P over a private network and until 
recently that worked just fine.

Previously, P was running Fedora 11 with the 2.6.30.10-105.2.16.fc11 
kernel; but now its running Fedora13 with the 2.6.33.6-147.fc13.

So, previously on B I could connect to (say) google.com:80 and traffic 
was redirect to the process listing on port 3128 via P' and the private 
link and everything was fine.

Now, unfortunately, the same connection from B is hits the REDIRECT rule 
but the process listening on port 3128 doesn't come out of the accept(2) 
syscall.  The same connection from A does work.  The only visible 
difference is that traffic from A appears to come into P from eth0 and 
traffic from B appears to come from eth1.   Inserting a LOG target 
immediately before the REDIRECT rule shows the packet hitting that 
REDIRECT (and one immediately after doesn't show anything so the 
REDIRECT is definitely matching).

Something seems to have changed between 2.6.30 and 2.6.33 and I'm at a 
loss to know what.  I've looked around a bit, but so far haven't found 
anything.

Hopefully someone listening will be able to say "oh, you need to do 
<some magic>" :-)  Or that this should never have worked in the first 
place because of something horrible I was relying on.

jch

             reply	other threads:[~2010-07-15  9:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-15  9:34 John Haxby [this message]
2010-12-06 11:32 ` REDIRECT problem John Haxby

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=4C3ED61A.4050303@oracle.com \
    --to=john.haxby@oracle.com \
    --cc=netfilter@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox