Strange traceroute behavior when using iptables/nat to redirect an IP

A client of mine has a network 10.0.1.0/24 that has the following systems (among others):

10.0.1.254 Main router 10.0.1.4 Linux server 10.0.1.8 Windows server 

 
The windows server hosts a rather old legacy application (that of course no one has the source code for) that serves a rather critical function for this client. This application wants to connect to a hard-coded IP address of 192.168.173.93, an IP that used to belong to a machine on a remote network 192.168.173.0/24 which is accessed over a VPN via 10.0.1.4, and to which all computers on the LAN have a static route to via 10.0.1.4.
 
The problem is that the machine that used to be 192.168.173.93 at the remote network no longer exists and it's software has been moved to a public VPS, 1.2.3.4.
 
One solution that I came up with was to add a couple of iptables rules on 10.0.1.4 to redirect packets from 10.0.1.8 bound for 192.168.173.93 to 1.2.3.4:
 

iptables -t nat -I PREROUTING -i br0 -s 10.0.1.8 -d 192.168.173.93 -j DNAT --to-destination 1.2.3.4 iptables -t nat -I POSTROUTING -o br0 -s 10.0.1.8 -d 1.2.3.4 -j SNAT --to-source 10.0.1.4 

 
(Note that br0 on 10.0.1.4 is an old bridge that used to bridge eth0 (the main LAN interface) and eth1 (legacy thinnet/BNC network that no longer exists.) br0 and eth0 show the same MAC address in ip link and ifconfig.)
 
Note about br0 on 10.0.1.4, that is used in the iptables rules; this is a left over bridge that presently only has eth0 and (unused) eth1 as members. br0 and eth0 show the same MAC address in ip link and ifconfig
 
And after that I can ping and make general connections to 192.168.173.93 from 10.0.1.8:

C:\Work>ping 192.168.173.93 Pinging 192.168.173.93 with 32 bytes of data: Reply from 192.168.173.93: bytes=32 time=37ms TTL=115 Reply from 192.168.173.93: bytes=32 time=36ms TTL=115 Reply from 192.168.173.93: bytes=32 time=36ms TTL=115 Reply from 192.168.173.93: bytes=32 time=36ms TTL=115 Ping statistics for 192.168.173.93: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 36ms, Maximum = 37ms, Average = 36ms 

 
The ping times above are consistent with what I see from directly pinging 1.2.3.4, so that looks good. But when I test with tracert, I see something really strange:

C:\Work>tracert 192.168.173.93 Tracing route to 192.168.173.93 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 192.168.173.93 2 <1 ms <1 ms <1 ms 192.168.173.93 3 8 ms 8 ms 8 ms 192.168.173.93 4 12 ms 13 ms 11 ms 192.168.173.93 5 15 ms 31 ms 15 ms 192.168.173.93 6 13 ms 13 ms 13 ms 192.168.173.93 7 21 ms 21 ms 21 ms 192.168.173.93 8 20 ms 19 ms 23 ms 192.168.173.93 9 21 ms 108 ms 74 ms 192.168.173.93 10 31 ms 31 ms 38 ms 192.168.173.93 11 37 ms 37 ms 37 ms 192.168.173.93 12 36 ms 39 ms 36 ms 192.168.173.93 13 37 ms 40 ms 37 ms 192.168.173.93 Trace complete. 

 
Which is the same length to a direct run of tracert when the extra hop of 10.0.1.4 is excluded (which is why there are two rows with <1 ms pings in the previous tracert):

C:\Work>tracert -d 1.2.3.4 Tracing route to 1.2.3.4 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 10.0.1.254 2 7 ms 8 ms 8 ms HOP-A 3 19 ms 11 ms 11 ms HOP-B 4 12 ms 11 ms 11 ms HOP-C 5 22 ms 14 ms 16 ms HOP-D 6 21 ms 21 ms 22 ms HOP-E 7 95 ms 59 ms 26 ms HOP-F 8 20 ms 21 ms 32 ms HOP-G 9 31 ms 30 ms 30 ms HOP-H 10 36 ms 36 ms 36 ms HOP-I 11 37 ms 36 ms 36 ms HOP-J 12 36 ms 36 ms 37 ms 1.2.3.4 Trace complete. 

 
Here is the output (gist.github.com) of tcpdump, which was running on 1.0.1.4, during the time tracert 192.168.173.93 ran on 10.0.1.8.
 
From the tcpdump output, it seems to me that the responses coming from each hop are not making their way back to 10.0.1.8 properly.
 
Could this be a limitation of iptables? Or am I missing something related to conntrack or similar, that would allow those hop responses to be seen as related? Or something else all together, like a better approach that I'm missing?
 
Thanks for any help, advise, and insights.