advowson: Good to hear. advowson: Yes, mostly. They try to keep the same port if possible. That may not work for you if you use DNAT to rewrite the Internet-side view of player's UDP ports to fixed values, but let MASQUERADE/SNAT guess what to use. If your configuration works, let it be. If it breaks, that mismatch is where I would start investigating.
advowson: I don't. Diablo uses TCP/6112 to talk to battle.net for logon/chat/matchmaking, but only UDP/6112 to talk to other players. (It also uses UDP/6112 to battle.net, but that's mostly just for latency measurement and the early warning that your firewall might not let others join. If not for the client locking out the create/join buttons when you fail to use UDP to battle.net, you wouldn't need UDP to battle.net to work at all.) If your tcp forwarding somehow misrouted traffic so that attempts to talk to battle.net were sent elsewhere, that would break affected users' ability to get on battle.net, but I would not expect any other consequences. What exactly went wrong when your bad tcp rule was present? Can you reproduce the failure at will by restoring the bad rule?

advowson: Could you post the resulting iptables rules? Anonymize your public IP if it's present.

advowson: -A PREROUTING -p tcp -m tcp --dport 6112 -j DNAT --to-destination $WIN10_VPN_ADDRESS

This is the culprit. It says any traffic crossing the device, destined for tcp/6112 on any system, shall be redirected to the Windows 10 machine. So when you tried to connect to battle.net, the connection was rerouted to your Windows 10 machine. Since you aren't running a private battle.net server there, the connection simply fails. If you needed this rule (you don't), you could fix it by adding -d $IP_OF_VPN_SERVER so that it only rewrites traffic directed to the device, but not traffic that merely crosses the device en route to something else.

More generally, your rules could use some attention. You don't need to route 6113-6119 to the same system. You want each of those to be sent to separate internal systems (but maybe this is just a glitch from anonymization). I would also add the -d $IP_OF_VPN_SERVER qualifiers to all your UDP nat rules, so that they do not trigger when you try to initiate a new UDP circuit with a previously unknown peer.