Thread (4 messages) 4 messages, 2 authors, 2015-06-27

Re: Why can't we SNAT (or inverse DNAT) in PREROUTING?

From: Francois Romieu <romieu@fr.zoreil.com>
Date: 2015-06-26 22:48:37

Possibly related (same subject, not in this thread)

Andy Lutomirski [off-list ref] :
[re-add netdev -- I assume you meant to reply all]
Thanks. Late friday.
On Fri, Jun 26, 2015 at 1:32 PM, Francois Romieu [off-list ref] wrote:
quoted
Andy Lutomirski [off-list ref] :
[...]
quoted
Could we add some option to do SNAT and inverse DNAT before routing?
I haven't used it for ages but what's wrong with iptables + fwmark ?

It takes place in PREROUTING.
This works, but it seems unnecessarily painful.  It means that all of
my policy rules have to be duplicated with fwmark rules based on '-m
conntrack' or similar.
I'd rather say that the fwmark rules will duplicate the SNAT rules since
your routing policy depends on the post SNAT source addresses. You'd
be right to complain it does not really help :o)
Shouldn't the order of operations be:

1. Check rp_filter.

2. Handle NAT.

3. Routing decision.

?
The admittedly painful fwmark part would still be needed for pre-NAT
source address based policy routing (assuming SNAT loses valuable policy
information). Life would be easier for your current requirements but
some different policy requirements would be unable to avoid the
fwmark/mangle style stuff.

Btw, the suggested scheme implies that filtering between SNAT and DNAT
would be done before routing, thus without INPUT vs FORWARD tainting.

It may be done but it would be a different beast and I can't help thinking
that routing and filtering would overlap.

-- 
Ueimor
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help