Sounds like this is an asymmetric routing issue. Your packets flow in via what I assume is the external IP of your home router (associated with your DDNS mapping) and they get to your transmission machine just fine. When transmission attempts to reply and establish the TCP connection it does so through the VPN tunnel, since the remote destination IP is not on your local home network. This is because the default route in the routing table of your transmission host is going to be pointing toward the tunnel interface. Most likely the seq number is also being randomized along the way back through your VPN provider and when/if the packet makes it back to your local machine it gets dropped since it's out of sequence.Thanks for posting this. I got mine set up and working, and I was able to verify it was using a completely different IP than my home external IP. But a side effect I didn't think about is I'm no longer able to access transmission remotely using the remote GUI set to my home DDNS address. Is there a workaround for this?
A solution would be to use the Internet facing IP provided by your VPN provider as the destination for your transmission gui session along with port forwarding through your VPN provider OR I guess if you are always going to be accessing the transmission gui from the same remote location (doubtful) you could add a static route to that network pointing toward the local home network interface.