7

My simple understanding of NAT is something like this could happen:

Two client PCs 192.168.1.2 and 192.168.1.3 open up a connection with src port = 12345. The gateway receives these and needs to use NAT, so one of them stays as 12345 and the other stays as 12346 when it goes out on the external IP 1.1.1.1.

192.168.1.2:12345                            1.1.1.1:12345 <-> 2.2.2.2:80
                  -----> 192.168.1.1 ----->
192.168.1.3:12345                            1.1.1.1:12346 <-> 3.3.3.3:443

When the packets come back in to 1.1.1.1 it has to map to the correct internal IP and port. This would need some kind of mapping table.

I wonder, how long would that table typically last?

  1. x Minutes/Hours?
  2. Until it sees a connection close down?

So for example if I have a protocol that irregularly sends data either way, is there a risk the mapping has gone and the other side sees the connection as closed (gets no Ack)?

In Linux, is there a way to see this table?

Alan
  • 189
  • 1
  • 7
  • All you're asking is easily googleable, so it seems as an artificial intelligence^W question. And why do you think 1.3 can't have 1.1:12345? O_o – poige Feb 23 '13 at 23:19
  • Perhaps if I altered my question, so both machines made two simultaneous connections to the same IP and port, that would clear up why it cannot happen? When a packet came into the gateway from the remote server, how would it know which 192.168.1/24 to switch it to? – Alan Feb 23 '13 at 23:28
  • — 2.2.2.2:80 and 3.3.3.3:443 look somewhat different, don't they? – poige Feb 23 '13 at 23:32
  • That's why I said perhaps if I altered my question. However, my question has nothing to do with how NAT decides whether to rewrite the source port, just that it does and how long typically that table entry would last. And I know I might be asking how long's a piece of string, but typical examples would be helpful. You're assuming in your comment a NAT implementation doesn't always rewrite src port , which is a false assumption to make. – Alan Feb 23 '13 at 23:55
  • i think nat connections are pesistent on time, if you like not pesistent connections you should use masquerade. Connections pesistent is the diference. – Brigo Feb 24 '13 at 01:15

1 Answers1

9

I wonder, how long would that table typically last?

These seem to be controlled by the following sysctl keys. Attaching as an example what I have on a machine of mine (never adjusted them, should be the defaults).

> sysctl -a 2>/dev/null | grep ip_conntrack_.*timeout
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2 = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_udp_timeout = 30
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180

So for example if I have a protocol that irregularly sends data either way, is there a risk the mapping has gone and the other side sees the connection as closed (gets no Ack)?

Seems like the timeout for established TCP connections is 5 days (432000 seconds). I guess you'll be fine, unless you are using a UDP based protocol.

In Linux, is there a way to see this table?

Yes. Either in /proc/net/nf_conntrack (third column) or using conntrack -L.

Additional resources:

chutz
  • 7,888
  • 1
  • 29
  • 59
  • 1
    Thank You. It's all nf_conntrack on my router but pointed me in the right direction. My router actually has nf_conntrack_tcp_timeout_established set to 1800. However, some connections start at 1800, and on each packet reset to 1800, however some, after a while, seem to go into a 300 second cycle - they're still ESTABLISHED, they're still TCP, nothing changes. A similar question I found on google here https://forum.openwrt.org/viewtopic.php?id=32494 . Do you have any idea why this is? – Alan Feb 24 '13 at 12:11
  • 1
    Yes, I actually have both `ip_conntrack` and `nf_conntrack`. Not sure how they differ, except that `ip_conntrack` has two more columns showing the IP version. The 300 timer reset could be related to the `nf_conntrack_tcp_timeout_unacknowledged` setting. – chutz Feb 24 '13 at 12:30
  • I just found [this post](http://lists.netfilter.org/pipermail/netfilter-devel/2007-February/027111.html) mentioning `ip_conntrack` as obsolete, so I updated my answer to not mention it. Also, the EXAMPLES section of the [conntrack man page](http://conntrack-tools.netfilter.org/conntrack.html) mentions one of the formats as an extended version of the other. – chutz Feb 24 '13 at 12:43
  • Yes it's nf_conntrack_tcp_timeout_unacknowledged causing the 300, even though there are ACKs every two packets, and the rate of data exchange is quite regular, every 10-15 seconds, so not sure why it's doing that. I proved it by changing it to 600. I did find a mailing list entry and a patch, but that was submitted in or prior to 2.6.31 and my kernel is 2.6.32. Odd, but I can at least explain this behaviour. The whole reason for asking this is I have a system and a user where a "keep alive" packet is sent every 7 minutes but the connection is dropping off despite this. – Alan Feb 24 '13 at 13:01