UDP replies being blocked?

[rosslevis]

I'm using Packet Sender to test a server app that receives commands via UDP and sends an answer back to the sender to the correct IP/Port. On the local LAN this only works if Packet Sender is added to the Windows Firewall. Why is that. Yet replies to outbound TCP messages are returned (via a different app). Is it standard practice for a firewall to block replies to outbound UDP messages? How would DNS work in that case?

Even if I do open the firewall or disable it, if the server app is run from a data center outside the LAN, an outbound UDP message gets to the server but no replies come back via the local router. I thought a router keeps track of outbound traffic and it will accept inbound on the same IP/port that it was sent to, but that also doesn't happen. The only way I get a response is if I quickly configure a port forward for the random UDP port Packet Sender decided to use to send from. Can someone help explain this please. I don't see how Zoom or similar UDP communications could work with these limitations.

[rosslevis]

Never mind. I now believe the problem is that the server is receiving the command using a UDPServer component and sending the reply back using a separate UDPClient component. There is a good reason the software is doing that, but there must be something else stored in the raw packet headers that doesn't match when it is sent back that way which routers and firewalls detect and block.

[dannagle]

I know you closed this discussion, but you are describing some common problems.

Some things to consider...

• UDP is connectionless. There will always be fully separate servers and clients.
• The standard is for the server to reply back to the source port of the client that made the request. A UDP client will typically launch at a random port and hold on to that port until it's task is complete. TCP clients do the same by acquiring its own random port and freeing the port when the connection is closed.
  • Packet Sender holds on to UDP ports until the app is closed because it makes no assumption of what actual task it is doing.
• Internet routers typically block UDP traffic, with the following caveats:
  • Port 53 is allowed in since DNS relies on it. Some may block until they detect a client requested it by sending to port 53
  • Non-standard UDP traffic (like conference services you mentioned) may be allowed in if a TCP connection has been negotiated to that source address first. If you are having UDP issues over the internet, try talking to a TCP server on the other end first.

Hope that helps others who find this thread.