Pekka Savola wrote: > I was mainly curious of the following: > > An internal node senda two UDP packets from 10.0.0.1:2000 and > 10.0.0.1:2001 to 1.1.1.1:3000 and 1.1.1.2:3001, respectively. The sources > of these are mapped in the NAT to 11.0.0.1:20000 and 11.0.0.1:20001.
The exact deails of the IP and port assignment depends on what type of NAT you are applying to the traffic. Most notable difference if comparing Linux-2.2 ipmasquerade and Linux-2.4 netfilter is that netfilter by default preserves the source port if it can (and is allowed), while the Linux-2.2 masquerade always remaps the source ports to a well known reserved ipmasquerade port range (61000-65095) to avoid conflicts with the masquerade host TCP/IP stack. > The crux is when someone sends a packet to either of these mapped ports, > assuming 11.0.0.1:20000; does the NAT discard the packet if it has source: > > - 1.1.1.1:3000 (of course not, always valid before the timeout) For UDP obviously this will be accepted. For TCP it depends on how picky the NAT implementation is about TCP sequence numbers etc. I don't have the exact details on how picky either of netfilter or ipchains is here, but there is a patch to iptables to increase the TCP window strictness of netfilter, and IIRC the Linux 2.2 masquerade has some TCP window validation of what is being accepted wiuthin the NAT session. > - 1.1.1.1:2999 (source IP ok, sport wrong) Neither iptables or ipchains will match the NAT session in such case. All 5 values of the protocol, source and destination IP and PORT must match for the packet to be considered part of the existing NAT session (protocol, source ip, source port, destination ip, destination port), with only two possible combinations that will match and possibly be considered part of the specific NAT session: a) Packets matching what is being sent by the internal host to the contacted server protcol = UDP, source = internal IP,PORT, destination = external IP,PORT b) Packets matching return traffic from the externally contacted host to the NAT address,port. protocol = UDP, source = external IP,PORT, destination = NAT IP,PORT > - 1.1.1.2:3001 (source IP in the map but for 10.0.0.1:20001, not :20000) As above.. won't match any of the two existing sessions. > etc. there are quite a few combinations. For each NAT session there is only two combinations of ip addresses and ports that will be accepted, as explained above. To further stress this fact, both implementations may even map multiple independent sessions to the same NAT ip,port as long as the session can be uniquely identified by the whole 5 value combination of addressing information. What will actually happen with non-matching packets is determined by your filtering rules, not the NAT engine. In case of Linux-2.2 IP-masquerading the packet will often be accepted and reach the masquerade host/router TCP/IP stack which then responds with a TCP RST or ICMP PORT UNREACH. > With "public port forwarding", the behaviour must not of course depend on > the source address or port. True, but each new combination will initiate a new NAT session independent from the other. This is true for both Linux-2.2 ipmasqurade PORTFW and Linux-2.4 netfilter NAT. Hope this better answers your query. Regards Henrik
