NAT tables and FILTER tables

NAT tables and FILTER tables

[Aseem Rastogi]

Hi,

I have a small query.

I have read that whenever a packet requesting a connection is 
encountered, NAT table is used. My question is : Does it mean that for 
new connection request packets ONLY NAT table is considered and not 
default FILTER table?

Thanks in advance.

Regards,
Aseem.

-- 
The end is always good. If it's not good, it's not the end.

Re: NAT tables and FILTER tables

[Aseem Rastogi]

in continuation:

i am actually trying to understand how nat and default filter table work 
together. my understanding is this:

when a packet is encountered it is either:

1. a new connection creation request packet.

2. a packet associated with a connection that has been mangled by NAT 
earlier.

3. a packet assiciated with a connection that has not been mangled by 
NAT earlier.

Each case goes like this:

Case 1: NAT table is considerd. Packet passes through PREROUTING chain, 
routing decision and then POSTROUTING chain.

Case 1a -- If either of them modified the packet, this packet and all 
subsequent packets of this connection DO NOT PASS THROUGH FILTER TABLE 
CHAINS.

Case 1b -- None of NAT tables modifies packet. It passes through FILTER 
table chains as usual.

Case 2: This packet follows the fate of its earlier packets. (PREROUTING 
AND POSTROUTING NAT table chains BUT NO FILTER table chains)

Case 3. Passes through FILTER TABLE chains.

is this correct??

Aseem Rastogi wrote:

> Hi,
>
> I have a small query.
>
> I have read that whenever a packet requesting a connection is 
> encountered, NAT table is used. My question is : Does it mean that for 
> new connection request packets ONLY NAT table is considered and not 
> default FILTER table?
>
> Thanks in advance.
>
> Regards,
> Aseem.
>


-- 
The end is always good. If it's not good, it's not the end.

Re: NAT tables and FILTER tables

[Rob Sterenborg]

> Hi,
>
> I have a small query.
>
> I have read that whenever a packet requesting a connection is
> encountered, NAT table is used. My question is : Does it mean that for
> new connection request packets ONLY NAT table is considered and not
> default FILTER table?

Looking at http://www.faqs.org/docs/iptables/traversingoftables.html a
packet uses all tables, but not all chains.

What chain a packet traverses depends on the routing decision (i.e. if a
packet is for the local host or not), and/or if you DROP or REJECT a
packet (in the mangle or nat table) before it can enter the filter table.
Let's say you SNAT or DNAT a packet ; that packet is altered but will
continue to traverse the tables (filter/FORWARD).


Gr,
Rob

Re: NAT tables and FILTER tables

[Jörg Harmuth]

Aseem Rastogi wrote:
> in continuation:
> 
> i am actually trying to understand how nat and default filter table work 
> together. my understanding is this:
> 
> when a packet is encountered it is either:
> 
> 1. a new connection creation request packet.
> 
> 2. a packet associated with a connection that has been mangled by NAT 
> earlier.
> 
> 3. a packet assiciated with a connection that has not been mangled by 
> NAT earlier.

Not really. Each packet is one of:

-> NEW packet with SYN set
-> NEW packet without SYN set
-> Part of a connection which has seen at least the SYN packet

Basically, a NEW packet means, that there is no entry in the conntrack 
table.

> Each case goes like this:
> 
> Case 1: NAT table is considerd. Packet passes through PREROUTING chain, 
> routing decision and then POSTROUTING chain.

No. Then filter/INPUT or filter/FORWARD - always.

> Case 1a -- If either of them modified the packet, this packet and all 
> subsequent packets of this connection DO NOT PASS THROUGH FILTER TABLE 
> CHAINS.
> 
> Case 1b -- None of NAT tables modifies packet. It passes through FILTER 
> table chains as usual.

No. See above.

> Case 2: This packet follows the fate of its earlier packets. (PREROUTING 
> AND POSTROUTING NAT table chains BUT NO FILTER table chains)
> 
> Case 3. Passes through FILTER TABLE chains.
> 
> is this correct??

No. It is almost vice-versa. Only NEW packet pass nat table, but all 
packets pass filter table.

If you apply NAT to the first packet, these subsequent packet will be 
NATed automagically, so - in your words - they follow the fate of their 
earlier packet concerning NAT.

HTH and have a nice time,

Joerg

PS: May I recommend Oskar Andreasson's excellent iptables tutorial at 
http://iptables-tutorial.frozentux.net/chunkyhtml/index.html ?

> Aseem Rastogi wrote:
> 
>> Hi,
>>
>> I have a small query.
>>
>> I have read that whenever a packet requesting a connection is 
>> encountered, NAT table is used. My question is : Does it mean that for 
>> new connection request packets ONLY NAT table is considered and not 
>> default FILTER table?

Re: NAT tables and FILTER tables

[Aseem Rastogi]

thanks joerg. this infact was the second line of thought that i had in 
mind. i just posted the first one :-).

Jörg Harmuth wrote:

> Aseem Rastogi wrote:
>
>> in continuation:
>>
>> i am actually trying to understand how nat and default filter table 
>> work together. my understanding is this:
>>
>> when a packet is encountered it is either:
>>
>> 1. a new connection creation request packet.
>>
>> 2. a packet associated with a connection that has been mangled by NAT 
>> earlier.
>>
>> 3. a packet assiciated with a connection that has not been mangled by 
>> NAT earlier.
>
>
> Not really. Each packet is one of:
>
> -> NEW packet with SYN set
> -> NEW packet without SYN set
> -> Part of a connection which has seen at least the SYN packet
>
> Basically, a NEW packet means, that there is no entry in the conntrack 
> table.
>
>> Each case goes like this:
>>
>> Case 1: NAT table is considerd. Packet passes through PREROUTING 
>> chain, routing decision and then POSTROUTING chain.
>
>
> No. Then filter/INPUT or filter/FORWARD - always.
>
>> Case 1a -- If either of them modified the packet, this packet and all 
>> subsequent packets of this connection DO NOT PASS THROUGH FILTER 
>> TABLE CHAINS.
>>
>> Case 1b -- None of NAT tables modifies packet. It passes through 
>> FILTER table chains as usual.
>
>
> No. See above.
>
>> Case 2: This packet follows the fate of its earlier packets. 
>> (PREROUTING AND POSTROUTING NAT table chains BUT NO FILTER table chains)
>>
>> Case 3. Passes through FILTER TABLE chains.
>>
>> is this correct??
>
>
> No. It is almost vice-versa. Only NEW packet pass nat table, but all 
> packets pass filter table.
>
> If you apply NAT to the first packet, these subsequent packet will be 
> NATed automagically, so - in your words - they follow the fate of 
> their earlier packet concerning NAT.
>
> HTH and have a nice time,
>
> Joerg
>
> PS: May I recommend Oskar Andreasson's excellent iptables tutorial at 
> http://iptables-tutorial.frozentux.net/chunkyhtml/index.html ?
>
>> Aseem Rastogi wrote:
>>
>>> Hi,
>>>
>>> I have a small query.
>>>
>>> I have read that whenever a packet requesting a connection is 
>>> encountered, NAT table is used. My question is : Does it mean that 
>>> for new connection request packets ONLY NAT table is considered and 
>>> not default FILTER table?
>>
>
>
>


-- 
The end is always good. If it's not good, it's not the end.

Re: NAT tables and FILTER tables

[/dev/rob0]

On Wednesday 2005-September-14 06:35, Rob Sterenborg wrote:
> Looking at http://www.faqs.org/docs/iptables/traversingoftables.html
> a packet uses all tables, but not all chains.

A more recent version of the same thing is at
    http://iptables-tutorial.frozentux.net/chunkyhtml/c951.html
However neither version has been updated to include the new raw table, 
which IIUC breaks that rule. Packets changed in the raw table do bypass 
the filter table, and perhaps others as well. I'm not using raw yet, 
thus am not sure of the details.

Joerg's response was accurate but might be said to suffer from TCP 
tunnel vision: SYN is only used in TCP. Connection tracking supports 
non-TCP protocols as well.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header