* Re: Questions on DNAT and pre/postrouting...
2004-07-20 21:02 Questions on DNAT and pre/postrouting Jeffrey C Albro
@ 2004-07-20 21:15 ` Antony Stone
2004-07-20 21:22 ` Antony Stone
2004-07-20 21:23 ` John A. Sullivan III
2 siblings, 0 replies; 4+ messages in thread
From: Antony Stone @ 2004-07-20 21:15 UTC (permalink / raw)
To: netfilter
On Tuesday 20 July 2004 10:02 pm, Jeffrey C Albro wrote:
> I understand how DNAT works in the prerouting change. You change the
> destination and out the packet goes to the preferred server. No problemo.
> But when the packet comes back, the failover box appears to SNAT the
> packet. I've seen this referred as un-DNATing.
Correct. If this did not happen then reply packets would not be routed
correctly.
> It makes perfect sense that due to the client expecting packets back from
> the address it sent them to that this is required behavior, but can this be
> turned off or controlled? I just found it odd that this happened with no
> iptables rules.
What do you mean - "this happened with no iptables rules"? How are you doing
DNAT with no iptables rules?
> What's up the the "no filtering" guideline for the PRE and POST routing
> chains?
PREROUTING and POSTROUTING chains have nat and mangle tables only; and things
happen in the background (as you have already referred to above) in the nat
and mangle tables.
Specifically, if you set any default policy other than ACCEPT on the nat or
mangle tables, you will be very lucky if things work.
> I'm doing it right now and it seems to work fine,
What are you doing? What filtering rules do you have in the nat table (and
why)?
> but WHY is this a problem, and how else would I do it?
Why is it a problem? Hopefully explained above.
How else would you do it? Put the filtering rules in the filtering tables,
in the INPUT or FORWARD chains.
> It seems that it would result in a longer ruleset if I had to do this in the
> FORWARD chain.
So?
> Is lightning going to strike me down?
Who knows? I think it depends mainly on where you live and how much time you
spend outside :)
Regards,
Antony.
--
"I don't mind that he got rich, but I do mind that he peddles himself as the
ultimate hacker and God's own gift to technology when his track record
suggests that he wouldn't know a decent design idea or a well-written hunk of
code if it bit him in the face. He's made his billions selling elaborately
sugar-coated crap that runs like a pig on [sedatives], crashes at the drop of
an electron, and has set the computing world back by at least a decade."
- Eric S Raymond, about Bill Gates
Please reply to the list;
please don't CC me.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Questions on DNAT and pre/postrouting...
2004-07-20 21:02 Questions on DNAT and pre/postrouting Jeffrey C Albro
2004-07-20 21:15 ` Antony Stone
@ 2004-07-20 21:22 ` Antony Stone
2004-07-20 21:23 ` John A. Sullivan III
2 siblings, 0 replies; 4+ messages in thread
From: Antony Stone @ 2004-07-20 21:22 UTC (permalink / raw)
To: netfilter
On Tuesday 20 July 2004 10:02 pm, Jeffrey C Albro wrote:
> I've seen this referred as un-DNATing. It makes perfect sense
> that due to the client expecting packets back from the address it sent
> them to that this is required behavior, but can this be turned off or
> controlled?
Sorry - forgot to reply to this bit.
I can think of two ways to avoid it:
1. Turn off connection tracking for the packets you don't want reverse NATted
(possibly all packets?) with the NOTRACK target.
2. Use iproute2 to do your NAT rules (I believe this is not stateful, and
therefore doesn't do automatic reverse NAT for you).
Regards,
Antony.
--
90% of networking problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.
Please reply to the list;
please don't CC me.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: Questions on DNAT and pre/postrouting...
2004-07-20 21:02 Questions on DNAT and pre/postrouting Jeffrey C Albro
2004-07-20 21:15 ` Antony Stone
2004-07-20 21:22 ` Antony Stone
@ 2004-07-20 21:23 ` John A. Sullivan III
2 siblings, 0 replies; 4+ messages in thread
From: John A. Sullivan III @ 2004-07-20 21:23 UTC (permalink / raw)
To: Jeffrey C Albro; +Cc: netfilter
On Tue, 2004-07-20 at 17:02, Jeffrey C Albro wrote:
> I'm trying to wrap my head around some iptables issues with a failover box
> I'm working on. The failover box has an interface to the outside world,
> and an interface to each server.
>
> I've read every FAQ and HOW-TO I can get my hands on. I wish the archives
> of this mailing list was searchable...
>
> Anyways, I have a few questions:
>
> I understand how DNAT works in the prerouting change. You change the
> destination and out the packet goes to the preferred server. No problemo.
> But when the packet comes back, the failover box appears to SNAT the
> packet. I've seen this referred as un-DNATing. It makes perfect sense
> that due to the client expecting packets back from the address it sent
> them to that this is required behavior, but can this be turned off or
> controlled? I just found it odd that this happened with no iptables
> rules.
>
> What's up the the "no filtering" guideline for the PRE and POST routing
> chains? I'm doing it right now and it seems to work fine, but WHY is this
> a problem, and how else would I do it? It seems that it would result in a
> longer ruleset if I had to do this in the FORWARD chain. Is lightning
> going to strike me down?
<snip>
Your questions are strangely related. I'm sure someone who knows the
internals of netfilter can give a better explanation but the answer is
that iptables is using connection tracking, i.e., it is stateful. When
a packet undergoes DNAT, an entry is made in the conntrack table and it
waits for the expected reply to the current state. When the packet
comes, it is matched in the state table and does not pass through the
tables and chains (except, I believe, the raw table).
That is why packets are un-DNAT'd without iptables rules. The stateful
inspection engine does all the magic. That is one reason one does not
want to implement filtering rules in the nat table -- at least I read
that the filter rules may not see all the packets. I confess to being a
little confused by that statement as, if the packets are accepted in the
nat table because they match the state table and thus bypass the filter
table, then I would think they would not hit the filter rules anyway!!
Perhaps someone with more knowledge of the internals can clarify that.
However, there is a second reason. What if you want to filter your DNAT
traffic (as you almost certainly want to do)? If it hits the accepting
filtering rule first, it will cease traversing the nat table and never
hit the DNAT rule. If it hits the DNAT rule and is accepted, it will
cease traversing the nat table and never hit the filter rule. It will
then pass to the filter table anyway to hit whatever rules you have and,
if you have none, the filter table policy. I do hope your filter table
policy is to DROP. I confess a strong preference for DENY all but
explicitly allowed approaches.
Hope this helps a bit - John
--
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com
---
If you are interested in helping to develop a GPL enterprise class
VPN/Firewall/Security device management console, please visit
http://iscs.sourceforge.net
^ permalink raw reply [flat|nested] 4+ messages in thread