IPfilter NAT and stalled TCP connexions

[Emmanuel Dreyfus]

Hello

I use IPFilter on a gateway, to perform 1:1 NAT mapping, and I have
an annoying problem with stalled TCP connexions.

As I understand, the default lifetime of a TCP mapping in the NAT table
is one minute. After one minute of inactivity for the TCP connexion, the
mapping vanishes. If the client sends data, the mapping is reinstantiated
and the TCP connexion resumes normally.

But if the servers sends data on a TCP connexion that has no NAT mapping
at the moment, the data will not get through. When later the client will
send data and reinstantiate the mapping, it has a hard time restoring
the TCP connexion to a usable state. It can remain hang for several
seconds, or just be disconnected.

Question: how can that be fixed? I canincrease the mapping lifetime,
but I suspect I will run into ressource shortage.

[Greg Troxel]

Post by Emmanuel Dreyfus
Hello
I use IPFilter on a gateway, to perform 1:1 NAT mapping, and I have
an annoying problem with stalled TCP connexions.
As I understand, the default lifetime of a TCP mapping in the NAT table
is one minute. After one minute of inactivity for the TCP connexion, the
mapping vanishes. If the client sends data, the mapping is reinstantiated
and the TCP connexion resumes normally.
But if the servers sends data on a TCP connexion that has no NAT mapping
at the moment, the data will not get through. When later the client will
send data and reinstantiate the mapping, it has a hard time restoring
the TCP connexion to a usable state. It can remain hang for several
seconds, or just be disconnected.
Question: how can that be fixed? I canincrease the mapping lifetime,
but I suspect I will run into ressource shortage.

Basically I think you have to increase the mapping lifetime. I think
ipfilter will remove mappings on connection close. I see your point
about resources limits, but that's what you get for violating the e2e
design of IP - if you need state in the middle, then you need it.

1 minute sounds crazy to me for a NAT timeout. I've run into tables set
for 1 hour and complained about them. I'd say try 8 hours and see how
that goes.

[Steven Bellovin]

Post by Greg Troxel

Post by Emmanuel Dreyfus
Hello
I use IPFilter on a gateway, to perform 1:1 NAT mapping, and I have
an annoying problem with stalled TCP connexions.
As I understand, the default lifetime of a TCP mapping in the NAT table
is one minute. After one minute of inactivity for the TCP connexion, the
mapping vanishes. If the client sends data, the mapping is reinstantiated
and the TCP connexion resumes normally.
But if the servers sends data on a TCP connexion that has no NAT mapping
at the moment, the data will not get through. When later the client will
send data and reinstantiate the mapping, it has a hard time restoring
the TCP connexion to a usable state. It can remain hang for several
seconds, or just be disconnected.
Question: how can that be fixed? I canincrease the mapping lifetime,
but I suspect I will run into ressource shortage.

Basically I think you have to increase the mapping lifetime. I think
ipfilter will remove mappings on connection close. I see your point
about resources limits, but that's what you get for violating the e2e
design of IP - if you need state in the middle, then you need it.
1 minute sounds crazy to me for a NAT timeout. I've run into tables set
for 1 hour and complained about them. I'd say try 8 hours and see how
that goes.

Agreed. (I have a little script -- while true; do sleep 60; echo -n .; done -- that I run on idle ssh connections when in hotels with crazy timeouts....)

--Steve Bellovin, http://www.cs.columbia.edu/~smb






--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Emmanuel Dreyfus]

Post by Steven Bellovin
Agreed. (I have a little script -- while true; do sleep 60; echo -n .; done -- that I run on idle ssh connections when in hotels with crazy timeouts....)

A I understand, 1 minute is the default on NetBSD.

src/sys/dist/ipf/netinet/ip_nat.c:
fr_defnatipage = 120, /* 60 seconds */

[Chuck Swiger]

A[s] I understand, 1 minute is the default on NetBSD.
fr_defnatipage = 120, /* 60 seconds */

Unless NetBSD has "sysctl net.inet.ip.ttl" set to less than 60, that low of a timeout can be expected to be too short. In fact, I'd suggest that setting NAT timeouts to a minimum of least 5 minutes due to:

% grep -i MAXTTL /usr/include/netinet/ip.h
#define MAXTTL 255 /* maximum time to live (seconds) */

...to avoid making assumptions about which platforms are involved. And if you want TCP keepalives to work for things like idle SSH connections, one should consider adjusting the default timeout for NAT to something greater than "sysctl net.inet.tcp.keepidle".

Regards,

[der Mouse]

Post by Emmanuel Dreyfus
I use IPFilter on a gateway, to perform 1:1 NAT mapping, and I have
an annoying problem with stalled TCP connexions.
As I understand, the default lifetime of a TCP mapping in the NAT
table is one minute. After one minute of inactivity for the TCP
connexion, the mapping vanishes. If the client sends data, the
mapping is reinstantiated and the TCP connexion resumes normally.

Any particular reason you're using a stateful NAT? This makes it sound
as though you really want a stateless NAT, one which just rewrites
addresses, without doing many-to-one mapping or stateful firewalling -
in which case you're either using the wrong tool or you're configuring
it wrong, I don't know ipf well enough to know which.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Emmanuel Dreyfus]

Post by Emmanuel Dreyfus
Question: how can that be fixed? I canincrease the mapping lifetime,
but I suspect I will run into ressource shortage.

Using bimap rules fixes the problem.

[Michael Graff]

Post by Steven Bellovin
Agreed. (I have a little script -- while true; do sleep 60; echo -n .; done -- that I run on idle ssh connections when in hotels with crazy timeouts....)

I just tweak the TCP keep-alive timer to trigger once every 60 seconds. :)

--Michael

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Michael Graff]

I don't think that sysctl is really a "time to live" in seconds as much
as the badly named IP header TTL value, which is decremented on each
forward through a router. It's loop prevention not NAT related.

--Michael

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Dennis Ferguson]

Post by Michael Graff
I don't think that sysctl is really a "time to live" in seconds as much
as the badly named IP header TTL value, which is decremented on each
forward through a router. It's loop prevention not NAT related.

It wasn't badly named when it was named, and the field wasn't just
for loop protection. Originally routers were required to decrement
the ttl by 1 for each second they held a packet, rounded up, with
the purpose being to protect TCP against (theoretical) corruption
from very-late-arriving segments. It was only later (RFC 1812) that
this behaviour was made optional, given that no almost routers had
implemented the time-based decrement and no TCP problems had ever been
observed in practice.

It is true, however, that this value has nothing to do with NAT.

Dennis Ferguson
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Daniel Carosone]

Post by Steven Bellovin
Agreed. (I have a little script -- while true; do sleep 60; echo
-n .; done -- that I run on idle ssh connections when in hotels with
crazy timeouts....)

ssh has the ServerAliveInterval option to do that for you. set & forget.

--
Dan.

[Daniel Carosone]

Post by Daniel Carosone
ssh has the ServerAliveInterval option to do that for you. set & forget.

Especially useful when the span of a tcp connection and its keepalives
is not the same as the span of the ssh session, such as when going
through certain types of proxies (socks, http connect, etc) that
terminate tcp.

See how easy it is to forget? :)

--
Dan.

[Steven Bellovin]

Post by Daniel Carosone

Post by Daniel Carosone
ssh has the ServerAliveInterval option to do that for you. set & forget.

Especially useful when the span of a tcp connection and its keepalives
is not the same as the span of the ssh session, such as when going
through certain types of proxies (socks, http connect, etc) that
terminate tcp.
See how easy it is to forget? :)

You're assuming, of course, that I want all that extra traffic all the time...

Yes, I have tinkered with my keep-alive settings, both for TCP and ssh. But they're tuned to *normal* middleboxes..

--Steve Bellovin, http://www.cs.columbia.edu/~smb






--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthias Scheler]

Post by Steven Bellovin
Agreed. (I have a little script -- while true; do sleep 60; echo -n .; done -- that I run on idle ssh connections when in hotels with crazy timeouts....)

Is there any reason you are not simply using ...

ClientAliveInterval 60

... in the "sshd_config" on the remote machine?

Kind regards