How to use DNAT

How to use DNAT

[Italo Valcy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Guys!

I'm in doubt about the correct use of DNAT, if I should use an alias
interface (like eth0:0) with the original target IP address or I should
use something to advertise the arp-reply for that IP (like farpd).

I'm asking this because when I tried to use the alias interface I've got
*some* packages being processed by INPUT chain of the filter table...

Do you guys have any ideia?


Thank you so much for any help!

- -- 
Saudações,

Italo Valcy :: http://wiki.dcc.ufba.br/~ItaloValcy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1dbSwACgkQfidLqjN6RNHb6wCeKUDzLjJiGKNVfM1H3W7EQxjA
V9wAnjaRmU/OLFQnGJ86N5vepct2TINz
=fokt
-----END PGP SIGNATURE-----

Re: How to use DNAT

[Jan Engelhardt]

On Thursday 2011-02-17 19:47, Italo Valcy wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hello Guys!
>
>I'm in doubt about the correct use of DNAT, if I should use an alias
>interface (like eth0:0)

eth0:0 is not an interface. That is ifconfig misleading you. Avoid this 
old and unmaintained tool.

Re: How to use DNAT

[Italo Valcy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jan,

Em 17-02-2011 16:03, Jan Engelhardt escreveu:

> eth0:0 is not an interface. That is ifconfig misleading you. Avoid this 
> old and unmaintained tool.

Thank you so much for your quickly reply and tip. I change the
configuration according to your tip and I use "ip addr add" to add a
secondary ip address (the target IP for DNAT), but unfortunately that
does not help: the packets are still going to INPUT chain, even with the
DNAT rule changing the DESTINATION of the packet.


Kind Regards, Italo.


- -- 
Saudações,

Italo Valcy :: http://wiki.dcc.ufba.br/~ItaloValcy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1ddFoACgkQfidLqjN6RNGBWgCfbva8mT/PyPkmzGg+OM1+lOad
UKkAniJ5wzWi2vq9qPsJAKuwpAStiTZx
=knvD
-----END PGP SIGNATURE-----

Re: How to use DNAT

[Pascal Hambourg]

Hello,

Italo Valcy a écrit :
> 
> I'm in doubt about the correct use of DNAT, if I should use an alias
> interface (like eth0:0) with the original target IP address

Target ? Do you mean the original destination address ?

> or I should
> use something to advertise the arp-reply for that IP (like farpd).

As long as incoming packets reach the interface, it does not matter how.

> I'm asking this because when I tried to use the alias interface I've got
> *some* packages being processed by INPUT chain of the filter table...

Please provide some details about the rule, packets...
Note that iptables' NAT ignores packets in the INVALID state.

Re: How to use DNAT

[Italo Valcy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Pascal,

Em 17-02-2011 17:05, Pascal Hambourg escreveu:
> 
> Target ? Do you mean the original destination address ?

Yes, that's it! ;)

> As long as incoming packets reach the interface, it does not matter how.

Yes, it just have to know how to reach the interface. Beacause of this
either I have to use the original destination address as a secondary
address of my firewall (machine running iptables) or start answer the
arp request for that IP. Right now, I'm using the secondary IP address
approach.

> 
> Please provide some details about the rule, packets...
> Note that iptables' NAT ignores packets in the INVALID state.

Well... so could be this: INVALID state... The packets are about a
netflow traffic (9996/UDP) comming to the firewall, which should be
redirected to a internal host (through the DNAT). How can I debug these
possible INVALID packets?


Thanks!


- -- 
Saudações,

Italo Valcy :: http://wiki.dcc.ufba.br/~ItaloValcy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1dk4oACgkQfidLqjN6RNG2tACglYQeFkqjl2HMXpzzLh0tJ3bY
aWwAoJj6t8t3v8q9vU14kO3m7dof0O5s
=ORCq
-----END PGP SIGNATURE-----

Re: How to use DNAT

[Steven Kath]

----- "Italo Valcy" <italo@dcc.ufba.br> wrote: -----
> > Please provide some details about the rule, packets...
> > Note that iptables' NAT ignores packets in the INVALID state.
> 
> Well... so could be this: INVALID state... The packets are about a
> netflow traffic (9996/UDP) comming to the firewall, which should be
> redirected to a internal host (through the DNAT). How can I debug
> these possible INVALID packets?

iptables -I FORWARD -p udp -m udp --dport 9996 -m state --state INVALID -j LOG --log-prefix "INVALID-FWD: " 
iptables -I INPUT -p udp -m udp --dport 9996 -m state --state INVALID -j LOG --log-prefix "INVALID-IN: " 

This will allow you to see matching traffic through the filter 
table's FORWARD and INPUT chains with the invalid state in dmesg. 

Also, bear in mind that the nat table is only consulted for 
packets with state NEW. If your UDP flow state transitions to 
ESTABLISHED before your NAT rule is created, the new rule will 
not be applied to that flow.  

You'd need to clear that connection from the table with 
conntrack-tools, flush the entire table, or let the connection 
expire from the table for it to be considered NEW again and 
compared against the nat rules. 

Re: How to use DNAT

[Pascal Hambourg]

Steven Kath a écrit :
> ----- "Italo Valcy" <italo@dcc.ufba.br> wrote: -----
>>
>> Well... so could be this: INVALID state... The packets are about a
>> netflow traffic (9996/UDP) comming to the firewall, which should be
>> redirected to a internal host (through the DNAT). How can I debug
>> these possible INVALID packets?
> 
> iptables -I FORWARD -p udp -m udp --dport 9996 -m state --state INVALID -j LOG --log-prefix "INVALID-FWD: " 
> iptables -I INPUT -p udp -m udp --dport 9996 -m state --state INVALID -j LOG --log-prefix "INVALID-IN: " 
> 
> This will allow you to see matching traffic through the filter 
> table's FORWARD and INPUT chains with the invalid state in dmesg. 

AFAIK, UDP packets cannot be INVALID.

> Also, bear in mind that the nat table is only consulted for 
> packets with state NEW. If your UDP flow state transitions to 
> ESTABLISHED before your NAT rule is created, the new rule will 
> not be applied to that flow.  

Actually it is even stricter : the nat rules are consulted only for the
first packet of a new flow ("connection"). The next packets skip the nat
rules even when the flow does not transition to ESTABLISHED (when there
is no packet in the reply direction).

> You'd need to clear that connection from the table with 
> conntrack-tools, flush the entire table, or let the connection 
> expire from the table for it to be considered NEW again and 
> compared against the nat rules. 

Re: How to use DNAT

[Italo Valcy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi guys,

Em 17-02-2011 20:41, Pascal Hambourg escreveu:
>> Also, bear in mind that the nat table is only consulted for 
>> packets with state NEW. If your UDP flow state transitions to 
>> ESTABLISHED before your NAT rule is created, the new rule will 
>> not be applied to that flow.  
> 
> Actually it is even stricter : the nat rules are consulted only for the
> first packet of a new flow ("connection"). The next packets skip the nat
> rules even when the flow does not transition to ESTABLISHED (when there
> is no packet in the reply direction).

Yes, you are correct, but I didn't understand this behaviour. I managed
to get the netflow traffic working again by stoping the netflow device,
wainting about one minute and starting again. Almost sure its the exact
explanation above. But, why this behavior???

I think this problem starts happening when I restart the iptables rules
and the traffic keeps going. Maybe in that moment, the packets does not
pass to NAT table anymore. How can I fix it? Do you have any ideias
guys? I'm using the rules generated by fwbuilder to start/restart the
firewall.


Thanks again for the help!


- -- 
Saudações,

Italo Valcy :: http://wiki.dcc.ufba.br/~ItaloValcy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1eaxIACgkQfidLqjN6RNHpQACgm6ISsVBVByr5PSRT8LSu1WRA
zwUAn1+VtJAxR42LfYS+aVHrTOXMQKbc
=9O4a
-----END PGP SIGNATURE-----

Re: How to use DNAT

[Atle Solbakken]

Den 18. feb. 2011 kl. 13.50 skrev Italo Valcy <italo@dcc.ufba.br>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi guys,
>
> Em 17-02-2011 20:41, Pascal Hambourg escreveu:
>>> Also, bear in mind that the nat table is only consulted for
>>> packets with state NEW. If your UDP flow state transitions to
>>> ESTABLISHED before your NAT rule is created, the new rule will
>>> not be applied to that flow.
>>
>> Actually it is even stricter : the nat rules are consulted only for  
>> the
>> first packet of a new flow ("connection"). The next packets skip  
>> the nat
>> rules even when the flow does not transition to ESTABLISHED (when  
>> there
>> is no packet in the reply direction).
>
> Yes, you are correct, but I didn't understand this behaviour. I  
> managed
> to get the netflow traffic working again by stoping the netflow  
> device,
> wainting about one minute and starting again. Almost sure its the  
> exact
> explanation above. But, why this behavior???
>
> I think this problem starts happening when I restart the iptables  
> rules
> and the traffic keeps going. Maybe in that moment, the packets does  
> not
> pass to NAT table anymore. How can I fix it? Do you have any ideias
> guys? I'm using the rules generated by fwbuilder to start/restart the
> firewall.
>

You flush the conntrack table.

# conntrack -F


Atle.

Re: How to use DNAT

[Pandu Poluan]

(sorry for top posting; Gmail mobile client can only reply by top posting)

If I flush the conntrack table, would the next packet be considered NEW?

Because AFAIK the nat table is checked only for NEW packets.

(That would also mean overly-secure rules like -A FORWARD -p tcp !
--syn -m state --state NEW -j DROP must be deleted, or temporarily
disabled)

Rgds,


On 2011-02-19, Atle Solbakken <atle@goliathdns.no> wrote:
>
>
> Den 18. feb. 2011 kl. 13.50 skrev Italo Valcy <italo@dcc.ufba.br>:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi guys,
>>
>> Em 17-02-2011 20:41, Pascal Hambourg escreveu:
>>>> Also, bear in mind that the nat table is only consulted for
>>>> packets with state NEW. If your UDP flow state transitions to
>>>> ESTABLISHED before your NAT rule is created, the new rule will
>>>> not be applied to that flow.
>>>
>>> Actually it is even stricter : the nat rules are consulted only for
>>> the
>>> first packet of a new flow ("connection"). The next packets skip
>>> the nat
>>> rules even when the flow does not transition to ESTABLISHED (when
>>> there
>>> is no packet in the reply direction).
>>
>> Yes, you are correct, but I didn't understand this behaviour. I
>> managed
>> to get the netflow traffic working again by stoping the netflow
>> device,
>> wainting about one minute and starting again. Almost sure its the
>> exact
>> explanation above. But, why this behavior???
>>
>> I think this problem starts happening when I restart the iptables
>> rules
>> and the traffic keeps going. Maybe in that moment, the packets does
>> not
>> pass to NAT table anymore. How can I fix it? Do you have any ideias
>> guys? I'm using the rules generated by fwbuilder to start/restart the
>> firewall.
>>
>
> You flush the conntrack table.
>
> # conntrack -F
>
>
> Atle.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
--
Pandu E Poluan - IT Optimizer
My website: http://pandu.poluan.info/