4 ms·

I'm not sure I understand. UDP is connection-less so it doesn't matter if it's client-server. In a TCP connection, the client initiates the connection so that f

I'm not sure I understand. UDP is connection-less so it doesn't matter if it's client-server. In a TCP connection, the client initiates the connection so that firewalls aren't an issue and that isn't a thing with UDP

jlokier 4y ago
*> In a TCP connection, the client initiates the connection so that firewalls aren't an issue and that isn't a thing with UDP That is a thing with UDP too. Firewalls (whether NAT or SPI) keep track of connection state with UDP in a similar way to how they do with TCP. Because UDP doesn't have the TCP SYN/ACK/FIN/RST flags, those firewalls have to use simpler heuristics for UDP, but they do keep track of connections. In detail, this means your client needs to send a UDP packet to your server, so that the firewall will add a connection entry to its table to allow more packets through in the server->client direction. Then your server needs to reply with a UDP packets back to the client's IP:PORT. After that there needs to be a steady trickle of traffic from the client, or the firewall will remove the connection entry. Firewalls vary, and some of them require the server sends from the same IP:PORT the client->server packet was sent to; some UDP server software fails to do this correctly, especially if the server has multiple IPs. This makes sense with NAT, because it's required for rewriting the IP:PORT values as they pass through the NAT firewall. But even without NAT, SPI firewalls operate a similar connection table and block server->client packets if there is no connection entry created and maintained by client->server packets first. With QUIC and HTTP/3 you can sometimes have a little more packet inspection than with plain UDP. This asymmetry means the client-server concept exists for UDP in practice, the same as with TCP.
- lordofgibbons 4y ago
  Very interesting, I wasn't aware firewalls kept track of that kind of information. Thanks for the explanation!

jlokier 4y ago

*> In a TCP connection, the client initiates the connection so that firewalls aren't an issue and that isn't a thing with UDP That is a thing with UDP too. Firewalls (whether NAT or SPI) keep track of connection state with UDP in a similar way to how they do with TCP. Because UDP doesn't have the TCP SYN/ACK/FIN/RST flags, those firewalls have to use simpler heuristics for UDP, but they do keep track of connections. In detail, this means your client needs to send a UDP packet to your server, so that the firewall will add a connection entry to its table to allow more packets through in the server->client direction. Then your server needs to reply with a UDP packets back to the client's IP:PORT. After that there needs to be a steady trickle of traffic from the client, or the firewall will remove the connection entry. Firewalls vary, and some of them require the server sends from the same IP:PORT the client->server packet was sent to; some UDP server software fails to do this correctly, especially if the server has multiple IPs. This makes sense with NAT, because it's required for rewriting the IP:PORT values as they pass through the NAT firewall. But even without NAT, SPI firewalls operate a similar connection table and block server->client packets if there is no connection entry created and maintained by client->server packets first. With QUIC and HTTP/3 you can sometimes have a little more packet inspection than with plain UDP. This asymmetry means the client-server concept exists for UDP in practice, the same as with TCP.

lordofgibbons 4y ago
Very interesting, I wasn't aware firewalls kept track of that kind of information. Thanks for the explanation!