Looking at logs posted for an unrelated issue indeed shows the traffic from TTN always originates from 1700. (Of course, as @kersing knows what he is talking about!)
As an aside, I think this works as expected: it seems the backend doesn’t always use the last port used by the gateway as the target port for PULL_RESP (downlinks). Instead, it seems it only changes targets ports for PULL_RESP when receiving a PULL_DATA message, not when receiving other packets such as an uplink or statistics. With [PUSH_DATA], [PUSH_ACK], [PULL_RESP] and so on being my own annotations to summarize the logs, note the different ports in each 1st and 3rd lines:
// port 49457
11:04:50.435723 IP 31.157.192.137.49457 > 52.169.76.203.1700: UDP, length 243 [PUSH_DATA, uplink]
11:04:51.254810 IP 52.169.76.203.1700 > 31.157.192.137.49457: UDP, length 4 [PUSH_ACK]
// port 44731
11:04:55.914887 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 198 [PULL_RESP, downlink]
11:04:58.718783 IP 31.157.192.137.44731 > 52.169.76.203.1700: UDP, length 12 [PULL_DATA]
11:04:58.944786 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 4 [ack?]
11:05:08.738834 IP 31.157.192.137.44731 > 52.169.76.203.1700: UDP, length 12 [PULL_DATA]
11:05:08.984790 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 4 [ack?]
// port 49457
11:05:13.950806 IP 31.157.192.137.49457 > 52.169.76.203.1700: UDP, length 111[PUSH_DATA, stat]
// port 49457
10:52:06.493745 IP 31.157.192.137.49457 > 52.169.76.203.1700: UDP, length 246 [PUSH_DATA, uplink]
10:52:07.219847 IP 52.169.76.203.1700 > 31.157.192.137.49457: UDP, length 4 [PUSH_ACK]
// port 44731
10:52:07.880705 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 173 [PULL_RESP, downlink]
// port 49457
10:52:13.933259 IP 31.157.192.137.49457 > 52.169.76.203.1700: UDP, length 111 [PUSH_DATA, stat]
10:52:14.419806 IP 52.169.76.203.1700 > 31.157.192.137.49457: UDP, length 4 [ack?]
// port 44731
10:52:15.298769 IP 31.157.192.137.44731 > 52.169.76.203.1700: UDP, length 12 [PULL_DATA]
10:52:15.540786 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 4 [ack?]
10:52:25.348910 IP 31.157.192.137.44731 > 52.169.76.203.1700: UDP, length 12 [PULL_DATA]
10:52:25.579806 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 4 [ack?]
// port 33372
10:19:53.487901 IP 2.43.193.163.33372 > 52.169.76.203.1700: UDP, length 247 [PUSH_DATA, uplink]
10:19:54.295617 IP 52.169.76.203.1700 > 2.43.193.163.33372: UDP, length 4 [ack?]
// port 44112
10:19:54.936678 IP 52.169.76.203.1700 > 2.43.193.163.44112: UDP, length 174 [PULL_RESP, downlink]
10:19:57.538524 IP 2.43.193.163.44112 > 52.169.76.203.1700: UDP, length 12 [PULL_DATA]
10:19:57.785606 IP 52.169.76.203.1700 > 2.43.193.163.44112: UDP, length 4 [ack?]
// port 33372
10:19:59.952094 IP 2.43.193.163.33372 > 52.169.76.203.1700: UDP, length 111 [PUSH_DATA, stat]
10:20:00.505729 IP 52.169.76.203.1700 > 2.43.193.163.33372: UDP, length 4 [ack?]
Again: very likely very much by design, if only as it works. 