Thanks for your reply. Several remarks: 1. We've seen the phenomenon of packets being sent unNATed. We've also seen that the timeout period affecting this phenomenon is the ip_ct_tcp_timeout_time_wait, which is set to 120 seconds by default. We have changed this value to 1 second to help us deal with this issue. 2. The fact that the connection tracking time-wait timeout affects the amount of time in which unNATed packets are sent out indicates that the connection was in the time-wait state in the connection tracking table. We've seen this is also true for connections whose TCP state was not time-wait, i.e., connections that were passively closed by us. It seems that the connection tracking and TCP state machine differ in this point. Not sure whether this is intended or not. 3. Regarding more liberal source port allocation, RFC 1122 (Requirements for Internet Hosts -- Communication Layers), section 4.2.2.13, states: "When a connection is closed actively, it MUST linger in TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime). However, it MAY accept a new SYN from the remote TCP to reopen the connection directly from TIME-WAIT state, if it: (1) assigns its initial sequence number for the new connection to be larger than the largest sequence number it used on the previous connection incarnation, and (2) returns to TIME-WAIT state if the SYN turns out to be an old duplicate." This effectively allows new connections to be opened on sockets in the time-wait state. We've seen this is true for virtually all operating systems in use today. I think it would be a good idea to have analogous behavior implemented in tproxy. -- Yuval
-----Original Message----- From: Balazs Scheidler [mailto:bazsi@balabit.hu] Sent: Mon, August 25, 2003 19:55 To: Yuval Pemper Cc: tproxy@lists.balabit.hu; sagig@radware.com Subject: Re: [tproxy] Question about warning message
On Sun, Aug 24, 2003 at 08:08:54AM +0300, Yuval Pemper wrote:
While running stress tests on our application, which uses the tproxy patch, we see the following warning messages in dmesg:
IP_TPROXY: error applying NAT mapping, hooknum=4 ....
This warning message comes from the function ip_tproxy_setup_nat_bidir in iptable_tproxy.c. It's printed if the result of calling ip_nat_setup_info is different than NF_ACCEPT.
I'm not sure what this warning means. The ip_tproxy_setup_nat_bidir function continues normally after the warning is printed out. Any help in shedding light on this will be greatly appreciated.
This means that the request NAT mapping to the given foreign addr:port pair was reserved by another possibly timewaiting connection. I am currently thinking on adding a feature which would make source port allocation more liberal.
This usually means that the connection initiated by the proxy will go out unNATed with the source address it originally bound to.
-- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 _______________________________________________ tproxy mailing list tproxy@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/tproxy