Thanks for the information.. still I don't understand how this should work, the explanation is a bit short. I also found this thread: http://www.readynas.com/forum/viewtopic.php?f=75&t=30019 (a bit old, but same discussion), it does not explain things to me though.
As far as I understand a NAT router does *not* simply allow in any data from an IP that you previously sent traffic to. At least the local port number of the peer must be correct as well - but how can the peers *or* the leaf networks server know this port? The port will be assigned by the NAT router and should be random. Example (sorry, it is very complicated to explain):
notation: <ip1:port1/ip2:port2> is a packet from IP1 to IP2/port2 that uses port1 as source port (each TCP connection is identified by such a quadrupel).
setup is peer1 <-> NAT1 <-> leaf <-> NAT2 <-> peer2
Peer1 contacts the leaf server over NAT and sends a SYN packet <peer1:port1/leafIP:port2>.
NAT1 Router assigns *new* local port port3, so the SYN packet is rewritten to <NAT1:port3/leafIP:port2> - this is what the leaf server sees.
NAT1 also will allow data back from <leafIP:port2> to <NAT1:port3> in.
server replies and peer 1 sees an ACK packet <leafIP/port2:peer1/port1> (NAT translates port number back, peer1 never gets to know the value of port3)
- SYN <peer1:port1/leafIP:port2>, rewritten to <NAT1:port3/leafIP:port2>
- ACK <leafIP:port2/NAT1:port3> arrives at NAT1 and NAT1 rewrites it:
- ACK <leafIP:port2/peer1:port1> arrives at peer1 (and peer1 does not know port3)
- NAT1 allows in packets like <leafIP:port2/NAT1:port3>
Same for peer2 (I assume both sides use teh same port2 as leaf sever port here):
- SYN <peer2:port4/leafIP:port2>, rewritten to <NAT2:port5/leafIP:port2>
- ACK <leafIP:port2/NAT2:port5> arrives at NAT2 and NAT2 rewrites it:
- ACK <leafIP:port2/peer2:port4> arrives at peer2 (and peer2 does not know port5)
- NAT2 allows in packets like <leafIP:port2/NAT2:port5>
Now I assume the server could send the information <NAT2/port5> to peer1 and <NAT1/port3> to peer2. But now what?
If peer1 would try to send data to <NAT2:port5>, that would cause NAT1 to set up a *new* relation (nothing was sent to that destination yet), so packets would then look like <NAT1:port6/NAT2:port5> (port6 is randomly chosen by NAT1) - but NAT2 would not let it in because neither source IP nor source port match.
If peer2 could then send data that appeared as <NAT2:port5/NAT1:port6> at NAT1, then NAT1 would let it in. But how could this be done? Nobody knows the value of port6 except the 2 NATs (not even the leaf server knows this value), and in addition, peer2 can't easily tell NAT2 to use port5 as local port number - that value is usually chosen randomly.
Of course it might be possible to guess those ports number if they are chosen sequentially (is this the trick? would not be very reliable), or some of the NAT protococols that NAT routers often implemment (also to allow Skype etc) might be used - there are protocols for port discovery and to open "holes" in the NAT router from a local peer. Hence my initial question.
There is an additional problem with non-matching SEQ/ACK numbers in the TCP connection, but there I imagine NAT routers don't really modify or check those, this is probably something only firewalls with deep inspection do (but I'm not 100% sure there).