I've heard that on some corporate networks, outbound traffic from the same user can hop around different "from" IPs. Does that break two-way UDP, or do the networks only act that way for TCP?
If it does break two-way UDP, is there a common way two-way UDP applications deal with it, besides falling back on TCP?
from the same user can hop around different "from" IPs. Does that break two-way UDP, or do the networks only act that way for TCP?
Yes, that does happen when you are using NAT with a pool of public addresses, but it doesn't break because the system performing the NAT keeps a translation table that maps things to the correct place.
Since UDP is connectionless those translation table entries do expire after a while though. Where 'a while' is defined locally on the firewall. The translation would break if nothing is sent or received after a certain period of time.
If you do have an UDP app that crosses a firewall you usually need to provide an option that sends periodic keep-alive messages so your NAT translation stays active. Ideally this value will be tune-able.
So long as the protocol used over UDP is sanely designed, this won't be a problem. If the IP address of one endpoint changes, as soon as the first datagram is sent by that end, the other end should update its destination IP to the new one.
This is only a problem for protocols that create their own "connection" on top of UDP and erroneously assume that the other end's IP address is fixed. So long as they use a sensible connection identifier inside each UDP datagram and update the IP address of the other end if it changes, there is no problem.
TCP, of course, does guarantee that its connections can be uniquely and persistently identified by the 4-tuple of source port, source IP, destination port, and destination IP. Every device that handles TCP is designed not to break this assumption. But if you want to implement connections over UDP, you have to create your own connection identifier. You can't use the 4-tuple of source port, source IP, destination port, and destination IP because devices that handle UDP are under no obligation not to break this assumption.
At least, you can't if you expect your "connections" to remain stable. If you don't mind if your "connections" break and have to be re-formed, then don't worry about it.
There are three possibilities:
The protocol layered over UDP does not need to support IP address changes, in which case it doesn't matter.
The protocol layered over UDP does need to support IP address changes and therefore does so, in which case there's no problem.
The protocol layered over UDP does need to support IP address changes but doesn't do so, in which case the protocol is broken and should be fixed.
The only way that addresses would "hop around" would be if traffic were redirected out of a different NAT gateway / firewall. In most cases this would be the result of some kind of failure.
The important part of all of this, however, is that when a UDP (or TCP) session is initiated from an internal (private) IP via a NAT gateway that the return traffic will come back to the outside address of said gateway and will be forwarded back to the initiating host. This maintains a consistent mapping of addresses for a given session. If traffic from a given session is shifted to a different external address then this session will break.
