All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: Altering firewall rules to enable NAT Reflection
Date: Sat, 08 Nov 2008 12:52:42 -0600	[thread overview]
Message-ID: <4915DFFA.3050904@riverviewtech.net> (raw)
In-Reply-To: <49157629.2020104@plouf.fr.eu.org>

On 11/8/2008 5:21 AM, Pascal Hambourg wrote:
> And make sure that traffic forwarded from eth1 to eth1 is ACCEPTed in 
> the filter/FORWARD chain.

*nod*

> Note both SNAT and MASQUERADE hide the real source address from the 
> server, which may be annoying for logging or access control purposes. 
> Source NAT is not required to avoid the "routing triangle" if the server 
> itself can route the return traffic to the NAT router. This can be 
> achieved with advanced routing on Linux. Alternatively, the router may 
> use the NETMAP target instead of SNAT or MASQUERADE to do a 1-to-1 
> mapping of the source address range into another range, so the original 
> source address can be retrieved.

Interesting points.

First, I'd make sure to note that I would SNAT / MASQUERADE / <what 
ever> /only/ the traffic from the local LAN (same subnet) and not /all/ 
the traffic that is being DNATed.  So... when the target server receives 
traffic it can know that any traffic coming from the NATing device's IP 
that the traffic is from said NATing device or the local LAN (same 
subnet).  This does not completely negate the negative impact on 
logging, but IMHO it does greatly reduce it.

I had not considered using advanced routing to cause the server to 
direct ""reply traffic to the local LAN by way of the NATing device. 
What / how would you go about doing this?  (I ask because I have not 
thought about it for more than 15 seconds.)  I suppose you could choose 
the alternate routing table based on a combination of the source port(s) 
and the destination IP address of the reply packets.  I.e. if the reply 
is coming from a service that has been DNATed and is going back to the 
local LAN then go ahead and send it by way of the NATing device.



Grant. . . .

  reply	other threads:[~2008-11-08 18:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-06 23:25 Altering firewall rules to enable NAT Reflection Simon
2008-11-07 19:00 ` Grant Taylor
2008-11-08 11:21   ` Pascal Hambourg
2008-11-08 18:52     ` Grant Taylor [this message]
2008-11-09 23:14   ` Simon
2008-11-10  1:26     ` Grant Taylor
2008-11-10  3:06       ` Simon
2008-11-10  4:39         ` Grant Taylor
2008-11-13  1:30           ` Simon

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=4915DFFA.3050904@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --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 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.