SIP/OK response to a SIP/BYE request is sent to wrong port

When a SIP/BYE request is sent to Asterisk it sends it’s SIP/OK to the NAT-Port it has received the message from. The problem is, that this message never arrives at the destination:

<— Received SIP request (414 bytes) from UDP:23.251.129.236:51723 —>
BYE sip:3e315314-9519-450e-a0fe-45912f493819@213.71.23.139:5060 SIP/2.0
Via: SIP/2.0/UDP wh1.24dial.com:5060;rport;branch=z9hG4bK123456789
From: sip:evj6xZZffPGL8gOmnx0KL@wh1.24dial.com:5060;tag=123456789
To: sip:018053557555@213.71.23.139;tag=ae356e6b-e90e-457d-9c17-8689f75eafd9
Contact: sip:evj6xZZffPGL8gOmnx0KL@wh1.24dial.com:5060
Call-ID: 4a75f291-3b82-4920-ad1e-2d43360ebeff
CSeq: 24500 BYE

<— Transmitting SIP response (337 bytes) to UDP:23.251.129.236:51723 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP wh1.24dial.com:5060;rport;received=23.251.129.236;branch=z9hG4bK123456789
Call-ID: 4a75f291-3b82-4920-ad1e-2d43360ebeff
From: sip:evj6xZZffPGL8gOmnx0KL@wh1.24dial.com;tag=123456789
To: sip:018053557555@213.71.23.139;tag=ae356e6b-e90e-457d-9c17-8689f75eafd9
CSeq: 24500 BYE
Content-Length: 0

On the other hand when Asterisk responds to a SIP/OK with an SIP/ACK it sends the message to the correct port:

<— Transmitting SIP request (1421 bytes) to UDP:23.251.129.236:5060 —>
INVITE sip:evj6xZZffPGL8gOmnx0KL@wh1.24dial.com:5060 SIP/2.0
Via: SIP/2.0/UDP 213.71.23.139:5060;rport;branch=z9hG4bKPj0bfc26d4-8b6c-46bb-8a65-e936430e86b9
From: sip:018053557555@213.71.23.139;tag=ae356e6b-e90e-457d-9c17-8689f75eafd9
To: sip:evj6xZZffPGL8gOmnx0KL@wh1.24dial.com
Contact: sip:3e315314-9519-450e-a0fe-45912f493819@213.71.23.139:5060
Call-ID: 4a75f291-3b82-4920-ad1e-2d43360ebeff
CSeq: 24500 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE, REGISTER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Content-Type: application/sdp
Content-Length: 745

<— Received SIP response (1250 bytes) from UDP:23.251.129.236:35623 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 213.71.23.139:5060;rport;branch=z9hG4bKPj0bfc26d4-8b6c-46bb-8a65-e936430e86b9;rport=5060;received=213.71.23.139
From: sip:018053557555@213.71.23.139;tag=ae356e6b-e90e-457d-9c17-8689f75eafd9
To: sip:evj6xZZffPGL8gOmnx0KL@wh1.24dial.com;tag=123456789
Contact: sip:evj6xZZffPGL8gOmnx0KL@wh1.24dial.com:5060
Call-ID: 4a75f291-3b82-4920-ad1e-2d43360ebeff
CSeq: 24500 INVITE
Content-Type: application/sdp
Content-Length: 780

<— Transmitting SIP request (384 bytes) to UDP:23.251.129.236:5060 —>
ACK sip:evj6xZZffPGL8gOmnx0KL@wh1.24dial.com:5060 SIP/2.0
Via: SIP/2.0/UDP 213.71.23.139:5060;rport;branch=z9hG4bKPjcde83bb3-4750-4869-96db-692806b049d5
From: sip:018053557555@213.71.23.139;tag=ae356e6b-e90e-457d-9c17-8689f75eafd9
To: sip:evj6xZZffPGL8gOmnx0KL@wh1.24dial.com;tag=123456789
Call-ID: 4a75f291-3b82-4920-ad1e-2d43360ebeff
CSeq: 24500 ACK
Content-Length: 0

Any ideas, what might be the problem?

Incorrect user expectations. I think that it is correct that responses are sent back towards the source. ACK is not a response in that sense.