All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jesse Gordon" <jesseg@nikola.com>
To: Philip Craig <philipc@snapgear.com>
Cc: netfilter@lists.netfilter.org
Subject: Re: Unmatchable packet?
Date: Mon, 28 Nov 2005 11:11:36 -0800	[thread overview]
Message-ID: <00d401c5f44f$8df8e560$5e00800a@printserver> (raw)
In-Reply-To: 438664B6.2090807@snapgear.com

Philip, Robert, and whoever else:

Thanks! You guys have done an outstanding job of explaining this to me.
It's all starting to make a little bit of sense!

----- Original Message ----- 
From: "Philip Craig" <philipc@snapgear.com>
Subject: Re: Unmatchable packet?
> Okay I can see what you are doing here, and it isn't going to
> work with standard iptables NAT.  Assymetrical routing and NAT
> are incompatible.
>
> Even your "working" case is not ideal, each direction is seeing
> only half the packets and so they can't keep state fully.  Anything
> that requires a NAT helper will fail.  eg FTP data connections

FTP might not fail since the one public routable IP is being mapped directly 
to exactly one non routable private IP,
so the asymetry should be invisable to either end. In any case, I agree --  
[ab]using iptables like this is not ideal.

>> It seems iptables has no problem matching and SNATting reply packets as 
>> long
>> as they aren't the reply packets generated
>> by a local server.
>
> No.  It has no problem matching and SNATing replies as long
> as they are the first packet of the connection that it sees.

I'd been assuming that the type of packet mattered -- but no, it's just 
whether it's the first seen by iptables.

> Yes.  You can use CONNMARK to mark connections that are initially
> received on the internal interface, and then use 'ip rule' and 'ip route'
> to route those packets back out the internal interface to the
> Box A, which will use its existing NAT mapping to correctly source
> NAT them automatically (ie no further NAT rules required).
>

This sounds like the way to go -- I'll learn what CONNMARK means, and how to 
use ip rule and route.

Thanks very much!

-Jesse 




      reply	other threads:[~2005-11-28 19:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-22 20:58 Unmatchable packet? Jesse Gordon
2005-11-22 21:28 ` Jesse Gordon
2005-11-23  0:46   ` Nikolai Georgiev
2005-11-23  1:46     ` Jesse Gordon
2005-11-23  6:05       ` Philip Craig
2005-11-23  7:03         ` Jesse Gordon
2005-11-23  7:19           ` Philip Craig
2005-11-24 11:48             ` Jesse Gordon
2005-11-24 14:29               ` Robert Nichols
2005-11-25  1:11               ` Philip Craig
2005-11-28 19:11                 ` Jesse Gordon [this message]

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='00d401c5f44f$8df8e560$5e00800a@printserver' \
    --to=jesseg@nikola.com \
    --cc=netfilter@lists.netfilter.org \
    --cc=philipc@snapgear.com \
    /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.