All of lore.kernel.org
 help / color / mirror / Atom feed
* FTP and connection tracking
@ 2002-12-13 14:16 Hans Jorgensen
  0 siblings, 0 replies; 2+ messages in thread
From: Hans Jorgensen @ 2002-12-13 14:16 UTC (permalink / raw)
  To: netfilter-devel

Dear list

I am currently developing an application which is using DNAT and 
masquerading. First an incoming packet is DNAT'ed to have as specific dest. 
ip. The it is masquerading when it is leaving the decided interface.

This works fine, but when I use FTP, the following shows up in the kernel 
log:

<4>ip_conntrack_in: related packet for c3a22310
<4>nat_expected: We have a connection!
<4>nat_expected: PASV cmd. 192.168.1.254->192.168.4.1
<4>nat_expected: IP to 192.168.4.1
<4>Found best for tuple c3d69db8: 6 10.0.0.8:1026 -> 192.168.4.1:11697
<4>nat_expected: We have a connection!
<4>nat_expected: PASV cmd. 192.168.1.254->192.168.4.1
<4>nat_expected: IP to 192.168.1.254
<4>Found best for tuple c3d69cf0: 6 192.168.1.254:1026 -> 192.168.4.1:11697
<4>Altering reply tuple of c3a22310 to tuple c3d69cd0: 6 192.168.4.1:11697 
-> 192.168.1.254:1026
<4>Mangling c3ad4140: SRC to 192.168.1.254 1026
<4>Confirming conntrack c3a22310

My question is:
Why does: "We have a connection!" and the following lines show up two times? 
Is the connection data traversing the same chain twice?

Does anybody know where I can find more information on how the code in 
connection tracking and NAT works?

Thanks in advance.

/Hans


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

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

* Re: FTP and connection tracking
@ 2002-12-17  8:09 Haitao Yu
  0 siblings, 0 replies; 2+ messages in thread
From: Haitao Yu @ 2002-12-17  8:09 UTC (permalink / raw)
  To: Hans Jorgensen, netfilter-devel

As I think, ftp nat's expected function is called twice when the first expected packet is in PREROUTING chain and POSTROUTING chain.

>Dear list
>
>I am currently developing an application which is using DNAT and 
>masquerading. First an incoming packet is DNAT'ed to have as specific dest. 
>ip. The it is masquerading when it is leaving the decided interface.
>
>This works fine, but when I use FTP, the following shows up in the kernel 
>log:
>
><4>ip_conntrack_in: related packet for c3a22310
><4>nat_expected: We have a connection!
><4>nat_expected: PASV cmd. 192.168.1.254->192.168.4.1
><4>nat_expected: IP to 192.168.4.1
><4>Found best for tuple c3d69db8: 6 10.0.0.8:1026 -> 192.168.4.1:11697
><4>nat_expected: We have a connection!
><4>nat_expected: PASV cmd. 192.168.1.254->192.168.4.1
><4>nat_expected: IP to 192.168.1.254
><4>Found best for tuple c3d69cf0: 6 192.168.1.254:1026 -> 192.168.4.1:11697
><4>Altering reply tuple of c3a22310 to tuple c3d69cd0: 6 192.168.4.1:11697 
>-> 192.168.1.254:1026
><4>Mangling c3ad4140: SRC to 192.168.1.254 1026
><4>Confirming conntrack c3a22310
>
>My question is:
>Why does: "We have a connection!" and the following lines show up two times? 
>Is the connection data traversing the same chain twice?
>
>Does anybody know where I can find more information on how the code in 
>connection tracking and NAT works?
>
>Thanks in advance.
>
>/Hans
>
>
>_________________________________________________________________
>STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
>http://join.msn.com/?page=features/junkmail

= = = = = = = = = = = = = = = = = = = =
			

				 
               Haitao Yu
               yuht@th-dascom.com.cn
					2002-12-17 

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

end of thread, other threads:[~2002-12-17  8:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-13 14:16 FTP and connection tracking Hans Jorgensen
  -- strict thread matches above, loose matches on Subject: below --
2002-12-17  8:09 Haitao Yu

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.