Re: Unmatchable packet?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx>
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



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux