All of lore.kernel.org
 help / color / mirror / Atom feed
* DNAT & SNAT delay
@ 2005-06-13 12:11 Martin Bangiev
  2005-06-14 13:16 ` Jan Engelhardt
  0 siblings, 1 reply; 7+ messages in thread
From: Martin Bangiev @ 2005-06-13 12:11 UTC (permalink / raw)
  To: netfilter-devel

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:)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* DNAT & SNAT delay
@ 2005-06-14  9:13 Martin Bangiev
  0 siblings, 0 replies; 7+ messages in thread
From: Martin Bangiev @ 2005-06-14  9:13 UTC (permalink / raw)
  To: netfilter

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:)




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: DNAT & SNAT delay
  2005-06-13 12:11 DNAT & SNAT delay Martin Bangiev
@ 2005-06-14 13:16 ` Jan Engelhardt
  2005-06-14 16:33   ` Ferry Huberts
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Engelhardt @ 2005-06-14 13:16 UTC (permalink / raw)
  To: Martin Bangiev; +Cc: netfilter-devel


> 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: DNAT & SNAT delay
  2005-06-14 13:16 ` Jan Engelhardt
@ 2005-06-14 16:33   ` Ferry Huberts
  2005-06-15  6:58     ` Martin Bangiev
  0 siblings, 1 reply; 7+ messages in thread
From: Ferry Huberts @ 2005-06-14 16:33 UTC (permalink / raw)
  To: 'Martin Bangiev'; +Cc: netfilter-devel

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
> 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: DNAT & SNAT delay
  2005-06-14 16:33   ` Ferry Huberts
@ 2005-06-15  6:58     ` Martin Bangiev
  2005-06-16 13:48       ` Jan Engelhardt
  0 siblings, 1 reply; 7+ messages in thread
From: Martin Bangiev @ 2005-06-15  6:58 UTC (permalink / raw)
  To: Ferry Huberts, netfilter-devel

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
>>
>>    
>>
>
>
>
>  
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: DNAT & SNAT delay
  2005-06-15  6:58     ` Martin Bangiev
@ 2005-06-16 13:48       ` Jan Engelhardt
  2005-06-16 13:52         ` Ferry Huberts
  0 siblings, 1 reply; 7+ messages in thread
From: Jan Engelhardt @ 2005-06-16 13:48 UTC (permalink / raw)
  To: Martin Bangiev; +Cc: netfilter-devel, 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?


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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: DNAT & SNAT delay
  2005-06-16 13:48       ` Jan Engelhardt
@ 2005-06-16 13:52         ` Ferry Huberts
  0 siblings, 0 replies; 7+ messages in thread
From: Ferry Huberts @ 2005-06-16 13:52 UTC (permalink / raw)
  To: 'Jan Engelhardt', 'Martin Bangiev'; +Cc: netfilter-devel

> > 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2005-06-16 13:52 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-13 12:11 DNAT & SNAT delay Martin Bangiev
2005-06-14 13:16 ` Jan Engelhardt
2005-06-14 16:33   ` Ferry Huberts
2005-06-15  6:58     ` Martin Bangiev
2005-06-16 13:48       ` Jan Engelhardt
2005-06-16 13:52         ` Ferry Huberts
  -- strict thread matches above, loose matches on Subject: below --
2005-06-14  9:13 Martin Bangiev

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.