A very unique DSTNAT and routing issue - I need a hint

We have a very unique configuration issue and I need a clue on how to solve this issue.
There is a data logger in our manufacturing area that reports data via UDP port 4567 to a public IP address (10.10.10.10 for this example)
I can not change the configuration of this data logger. It is hard wired.
The Rb450G that is the gateway at the remote site has public access AND a Private VPN connection to the SAME server via a private address 172.44.10.10.
The requirements are:
When then VPN is connected the UDP packets must to go over the vpn to the private address of 172.44.10.10.
When the VPN is down we need the UDP packets to go over the Internet to the public address of 10.10.10.10.
There is NEVER a reverse connection or response from the remote server to these udp packets.

I have been marking the packets and the connections to the DSTNAT but when the VPN changes state things start going wrong and the RB starts losing memory resources.
I can and have worked with scripts to delete connections and disable the DSTNAT on demand.
I have read and tried the PCC wiki setups.

Can and will any of you give me a HINT as to how to go with this?

When this is working I WILL publish a wiki on this special configuration.

thanks

Here’s how I would approach it. Not tested, but it works in my head. I am also assuming that the hard coded public IP is correct and that you only need to destination NAT if the VPN is up - the packet is untouched if the VPN is down.

You’ll need an IP you can test only across the VPN tunnel. I’m assuming your example of 172.44.10.10 (which, btw, is a public IP address - if this is a real IP example you guys screwed up your RFC1918 space).

Make a mangle rule in prerouting that marks connections to the public IP 10.10.10.10 when established from a source address of 1.1.1.1 (the data logger) from being the “manufacturing” interface, in the prerouting chain. This will be evaluated before destination NAT:

/ip firewall mangle
add chain=prerouting in-interface=manufacturing src-address=1.1.1.1 dst-address=10.10.10.10 protocol=udp dst-port=4567 comment="datalogger-vpn-is-up" action=mark-connection new-connection-mark="datalogger-vpn-is-up"

Then make a destination NAT rule to push the connection through the VPN only evaluated for connections with that mark:

/ip firewall nat
add chain=dstnat connection-mark="datalogger-vpn-is-up" action=dst-nat to-address=172.44.10.10

Now for triggering. Make a NetWatch entry for 172.44.10.10. That will cause the router to monitor 172.44.10.10 via ICMP, and run the down event script when the ping drops, and the up event script when the ping comes back up.
Down script:

/ip firewall mangle { disable [find comment="datalogger-vpn-is-up"] }

Up script:

/ip firewall mangle { enable [find comment="datalogger-vpn-is-up"] }

That way connections only get marked when the VPN is up, and destination NAT is only run if the connection is marked.

If my assumption that the right public IP is automatically chose is incorrect, just add another destination NAT rule further down the list. Assuming 10.10.10.10 would have to be sent to 11.11.11.11:

/ip firewall nat
add chain=dstnat in-interface=manufacturing src-address=1.1.1.1 dst-address=10.10.10.10 protocol=udp dst-port=4567 action=dst-nat to-address=11.11.11.11

I’m curious if it works.