0

Let's say I have a client and server. Client is behind NAT and server is public.

Client wants to have a session with the server.

Let's say client is on 192.168.1.1, NAT on 192.168.1.2 private IP addresses. And NAT on 50.0.0.1 and server on 50.0.0.2 public IP addresses.

Client sends the UDP/IP (hopefully it's similar with TCP/IP) packet to the server. This packet has its source IP 192.168.1.1 and source port let's say 1000 (selected randomly), also has destination port 50.0.0.2 and destination port 2000, as this is the port application runs on the server.

The TCP/IP packet arrives at NAT which changes the source IP to 50.0.0.1 and port let's say 5000 (selected randomly) and routes to the server.

The server sends the response packet with destination IP 50.0.0.1 and port 5000.

The NAT changes the destination IP of the packet to 192.168.1.1 and destination port to 1000.

  1. Now, can the server send many UDP/IP packets to the same IP 50.0.0.1 and port 5000, and all packets will be forwarded to the client 192.168.1.1 port 1000?

  2. If so, for how long will this port 5000 on the public side of NAT forward the packets to the mentioned client?

  3. Only the packets with the source IP 50.0.0.2 and source port 2000 will be forwarded to the client?

14
  • 1
    are you asking about the differances between TCP and UDP as regards NAT? UDP does NAT very differantly than TCP does, since TCP contains information about the virtual circuit that doesn't exist for UDP, so you can't tell that a given packet is part of an existing flow. Apr 17, 2018 at 16:12
  • 2
    @FrankThomas TCP does NOT contain information about the virtual circuit - and to do this would, at least in part, break dynamic routing used by all very large ISP's. techrepublic.com/article/exploring-the-anatomy-of-a-data-packet shows the contents of a UDP and TCP header and explains how TCP negotiates a reliable connection (using acknowledgements and packet sequences, not virtual circuit information)
    – davidgo
    Apr 17, 2018 at 16:32
  • @FrankThomas not to defend what frank is saying, since he said UDP does NAT which is absolute nonsense, but regarding virtual circuits, where he says TCP does contain info on virtual circuit and you say it doesn't. This says it does en.wikipedia.org/wiki/Virtual_circuit says "it is possible to use TCP as a virtual circuit, since TCP includes segment numbering that allows reordering on the receiver side to accommodate out-of-order delivery."
    – barlop
    Apr 17, 2018 at 16:57
  • @barlop What do you mean by "UDP does not do NAT"? And virtual circuit in the sense you mention is not the same as Fran mentions. In your text is about reordering which makes it seam that packet arrive through channel (circuit). But UDP and TCP are the same regarding the identification of the flow - by IP and port number only (although TCP uses both source and destination and UDP only destination).
    – croraf
    Apr 17, 2018 at 18:00
  • 1
    ok, clearly I misspoke, please substitute the word "Connection" for "virtual circuit". TCP has states of connectivity controlled by flags and syn/ack values that provide ordinality and continuity to a flow of packets (eg you know they are all related to the same flow, and what order they should be in, regardless of what order they arrive in). for TCP NAT uses these characteristics to determine connection states. UDP has to use tricks like timing windows and address matching to determine that a pair of UDP packets are related to each other. Apr 17, 2018 at 19:49

1 Answer 1

3

Answers:

  1. Yes.
  2. This depends on the implementation of NAT for the device. In Linux this can be tuned by editing /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_*
  3. Yes - unless there are "related" ports recognised by NAT, in which case additional NAT modules are used to work out what is related (at least on Linux)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .