The responder sends the reply to whichever address/port the initiator appears to be using. NAT-T is no different in this regard than any other protocol like HTT

The responder sends the reply to whichever address/port the initiator appears to be using. NAT-T is no different in this regard than any other protocol like HTTP, QUIC, WireGuard, etc. To be fair, it also suffers from the same issue as all of those: when a NAT gateway decides to remap the port (because it hasn't seen traffic in 30 seconds, because it got rebooted, w'ever) then traffic from the responder to the initiator is dropped. So the initiator has to constantly send keepalive messages so the responder has an up-to-date notion of where to send packets. The shorter the interval the more the wasteful traffic; the longer the interval then the more often you get frustrating delays. I've personally run into an issue where a stateful UDP gateway (downstream from the NAT gateway) had a 30s timeout on UDP flows. The IPSec initiator also sent NAT-T keepalives at 30s intervals. Because of drift and jitter, every few hours the 30s periods would synchronize so that the gateway dropped the state immediately before the next keepalive passed through, resulting in a very annoying 30s pause in activity. Most traffic was going from responder to initiator as the VPN was effectively a reverse proxy onto a corporate LAN, so one result was SSH sessions becoming unresponsive for 30s. To reiterate, there are no simple solutions to these sorts of problems.