[tproxy] Question about warning message
Yuval Pemper
YuvalP@Radware.com
Tue, 26 Aug 2003 08:42:46 +0200
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
>