DNAT & SNAT delay

DNAT & SNAT delay

[Martin Bangiev]

Hi guys,
I have two applications based in different networks that has to 
communicate with each other using many small UDP packets. Due to 
security reasons I set the firewall for SNAT and DNAT dynamically. Here 
is the exact situation.

Client1:
IP - 10.0.0.2
Client2:
IP - 172.16.0.2
Firewall:
IP1 - 10.0.0.1
IP2 - 172.16.0.1

Client1 sends it's datagrams to the Firewall:IP1
Client2 sends it's datagrams to the Firewall:IP2

Just before the communication starts I add rules to DNAT udp packets 
from Client1 to Client2, and to SNAT packets to Client2 to be from 
Firewall:IP2. I do it for the Client2 respective (of course I set up the 
ports too).
The problem is that the NAT starts with about 30 seconds delay. tcpdump 
shows the packets are coming from Client1 but they are not SNATed & 
DNATed. The counters of the rules however counts the packets. Once the 
packets begin to be NATed the counters stops.
Can you please tell me where this delay can be coming from?
Thanks in advance:)

Re: DNAT & SNAT delay

[Jan Engelhardt]

> Just before the communication starts I add rules to DNAT udp packets from
> Client1 to Client2, and to SNAT packets to Client2 to be from Firewall:IP2. I
> do it for the Client2 respective (of course I set up the ports too).
> The problem is that the NAT starts with about 30 seconds delay. tcpdump shows

> Can you please tell me where this delay can be coming from?
> Thanks in advance:)

Exactly 30? Then this:

the default conntrack time-to-live for udp "connections" is 30 seconds so you 
need to wait 30 seconds until the old-and-stale udp conn (the one "without" 
DNAT/SNAT) expires.

Well, that's a guess.



Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

RE: DNAT & SNAT delay

[Ferry Huberts]

You can also use a hack I sometimes use:
- reconfigure rules
- set the connection tracking timeout for your connection type to zero in
/proc
- wait 1 second
- restore the connection tracking timeout for your connection type in /proc

Or use connection tracking flushing; I had a short discussion with Pablo
Neira a while ago on this on the list but continued it privately because his
solution was for 2.6 only and I use 2.4

I have a 2.4 kernel patch for connection tracking entry flushing and Pablo
can point you to a 2.6 solution (but first check the list for our
discussion...)

Good luck!

________________________________

Ferry Huberts

 Linux Rocks!  
________________________________

Brady's First Law of Problem Solving: 

When confronted by a difficult problem, you can solve it more easily by
reducing it to the question: "How would the Lone Ranger have handled this?" 

 

> -----Original Message-----
> From: netfilter-devel-bounces@lists.netfilter.org 
> [mailto:netfilter-devel-bounces@lists.netfilter.org] On 
> Behalf Of Jan Engelhardt
> Sent: Tuesday, June 14, 2005 15:17
> To: Martin Bangiev
> Cc: netfilter-devel@lists.netfilter.org
> Subject: Re: DNAT & SNAT delay
> 
> 
> > Just before the communication starts I add rules to DNAT 
> udp packets 
> > from
> > Client1 to Client2, and to SNAT packets to Client2 to be from 
> > Firewall:IP2. I do it for the Client2 respective (of course 
> I set up the ports too).
> > The problem is that the NAT starts with about 30 seconds delay. 
> > tcpdump shows
> 
> > Can you please tell me where this delay can be coming from?
> > Thanks in advance:)
> 
> Exactly 30? Then this:
> 
> the default conntrack time-to-live for udp "connections" is 
> 30 seconds so you need to wait 30 seconds until the 
> old-and-stale udp conn (the one "without" 
> DNAT/SNAT) expires.
> 
> Well, that's a guess.
> 
> 
> 
> Jan Engelhardt                                                
>                
> --                                                            
>                 
> | Gesellschaft fuer Wissenschaftliche Datenverarbeitung 
> Goettingen, Am 
> | Fassberg, 37077 Goettingen, www.gwdg.de
> 

Re: DNAT & SNAT delay

[Martin Bangiev]

Thanks guys
I'm using 2.6 kernel and I did
echo "0" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
everything works perfectly now:)

Ferry Huberts wrote:

>You can also use a hack I sometimes use:
>- reconfigure rules
>- set the connection tracking timeout for your connection type to zero in
>/proc
>- wait 1 second
>- restore the connection tracking timeout for your connection type in /proc
>
>Or use connection tracking flushing; I had a short discussion with Pablo
>Neira a while ago on this on the list but continued it privately because his
>solution was for 2.6 only and I use 2.4
>
>I have a 2.4 kernel patch for connection tracking entry flushing and Pablo
>can point you to a 2.6 solution (but first check the list for our
>discussion...)
>
>Good luck!
>
>________________________________
>
>Ferry Huberts
>
> Linux Rocks!  
>________________________________
>
>Brady's First Law of Problem Solving: 
>
>When confronted by a difficult problem, you can solve it more easily by
>reducing it to the question: "How would the Lone Ranger have handled this?" 
>
> 
>
>  
>
>>-----Original Message-----
>>From: netfilter-devel-bounces@lists.netfilter.org 
>>[mailto:netfilter-devel-bounces@lists.netfilter.org] On 
>>Behalf Of Jan Engelhardt
>>Sent: Tuesday, June 14, 2005 15:17
>>To: Martin Bangiev
>>Cc: netfilter-devel@lists.netfilter.org
>>Subject: Re: DNAT & SNAT delay
>>
>>
>>    
>>
>>>Just before the communication starts I add rules to DNAT 
>>>      
>>>
>>udp packets 
>>    
>>
>>>from
>>>Client1 to Client2, and to SNAT packets to Client2 to be from 
>>>Firewall:IP2. I do it for the Client2 respective (of course 
>>>      
>>>
>>I set up the ports too).
>>    
>>
>>>The problem is that the NAT starts with about 30 seconds delay. 
>>>tcpdump shows
>>>      
>>>
>>>Can you please tell me where this delay can be coming from?
>>>Thanks in advance:)
>>>      
>>>
>>Exactly 30? Then this:
>>
>>the default conntrack time-to-live for udp "connections" is 
>>30 seconds so you need to wait 30 seconds until the 
>>old-and-stale udp conn (the one "without" 
>>DNAT/SNAT) expires.
>>
>>Well, that's a guess.
>>
>>
>>
>>Jan Engelhardt                                                
>>               
>>--                                                            
>>                
>>| Gesellschaft fuer Wissenschaftliche Datenverarbeitung 
>>Goettingen, Am 
>>| Fassberg, 37077 Goettingen, www.gwdg.de
>>
>>    
>>
>
>
>
>  
>

Re: DNAT & SNAT delay

[Jan Engelhardt]

> Thanks guys
> I'm using 2.6 kernel and I did
> echo "0" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
> everything works perfectly now:)

Does not that turn off UDP connection tracking at all?


Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

RE: DNAT & SNAT delay

[Ferry Huberts]

> > Thanks guys
> > I'm using 2.6 kernel and I did
> > echo "0" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
> > everything works perfectly now:)
> 
> Does not that turn off UDP connection tracking at all?

Yes it does.

That's why I said to restore the timeout value AND that it's a hack...

It's better to use the libctnetlink stuff and conntrack from Pablo (although
they're in CVS only for now)

Ferry

DNAT & SNAT delay

[Martin Bangiev]

Hi guys,
I have two applications based in different networks that has to 
communicate with each other using many small UDP packets. Due to 
security reasons I set the firewall for SNAT and DNAT dynamically. Here 
is the exact situation.

Client1:
IP - 10.0.0.2
Client2:
IP - 172.16.0.2
Firewall:
IP1 - 10.0.0.1
IP2 - 172.16.0.1

Client1 sends it's datagrams to the Firewall:IP1
Client2 sends it's datagrams to the Firewall:IP2

Just before the communication starts I add rules to DNAT udp packets 
from Client1 to Client2, and to SNAT packets to Client2 to be from 
Firewall:IP2. I do it for the Client2 respective (of course I set up the 
ports too).
The problem is that the NAT starts with about 30 seconds delay. tcpdump 
shows the packets are coming from Client1 but they are not SNATed & 
DNATed. The counters of the rules however counts the packets. Once the 
packets begin to be NATed the counters stops.
Can you please tell me where this delay can be coming from?
Thanks in advance:)