-1

THIS IS ALL UDP

Let say I have an internal port 25000 that isn't forwarded.

I send a UDP Message through that port to a server.

I now listen to that 25000 port locally for a reply from that server.

The server received my message.

The server thinks the port the message came from is 27833.

How much time does the server have to send a message back to me through port 27833?

If I locally keep listening to port 25000 will the 27833 port stay open indefinitely until I stop listening?

savvamadar
  • 306
  • 2
  • 13
  • That completely depends on the configuration of the NAPT device. It could be a few seconds to hours. Security-conscious people will lower it to just the point where things start to fail, then add a small amount of time to that. – Ron Maupin Mar 04 '19 at 17:50

1 Answers1

1
  1. I'm not an expert but I think the timeout of the forwarding of the port on the NAT will not be influenced because you listen to new datagram on a computer behind your NAT (As only the OS will know you want to read those packets, not the NAT).

  2. For the time the port will be forwarded by the NAT, I've find this response on stackoverflow: For how long a router keeps records in the NAT and can they be reused forwarding requests from other hosts? (Shortcut from the response, in practice less than 120 sec)

  • Very interesting that the thread cites 60 seconds. I'm trying to write a UDP punch through application essentially the "Host" pc sends a UDP packet to a server and that server notes the remote ip and the remote port of that packet. Then a client trying to connect to the "Host" pc sends a request for the info to the server. I've written UDP Punch-through applications before and the mapping of internal to external ports has lasted for a while. I never stress tested it but I was able to connect to the pc a few minutes after the original message had been sent. – savvamadar Mar 04 '19 at 17:34
  • 1
    Maybe you where keeping sending packet in your punch-through process? (I believe that would keep the record alive while you are sending packets) or you had a router that was keeping the record longer than the average, or the thread is wrong. – user3244171 Mar 04 '19 at 17:51
  • 1
    No it didn't keep sending packets. So I guess I can just add a way for the client to request that the host reconnect to the server if it can't connect after x seconds and try again. – savvamadar Mar 04 '19 at 17:54