For reference, the relevant section of the HOWTO is here, though I suspect you've followed that.
The first thing I'd try is to remove the 'local', that is the command should be
push "redirect-gateway def1"
and not
push "redirect-gateway local def1"
The local flag only works if all of your clients are on the same subnet.
A couple of other things to be aware of are that DNS traffic is routed through the vpn so you won't be able to resolve addresses unless you've dealt with that. DHCP can also get forwarded though it doesn't look like that should happen in your case as you're using a routed not a bridged VPN, but might be worth checking anyway.
It's because the OUTPUT chain only acts on packets originating from a local process. (See this useful image here.)
If you replace (or supplement if you still want to connect form the gateway) that rule with:
iptables -t nat -A PREROUTING -p tcp --dport 3306 -j DNAT --to 10.8.0.51
And, if you haven't already allowed for the traffic:
iptables -t filter -A FORWARD -p tcp -d 10.8.0.51 --dport 3306 -j ACCEPT
Then your connection should go through. Since it's already working form the gateway, you can be sure MySQL is listening correctly and that its server is accepting the connection.
However, I question whether you actually need NAT at all. Routing alone should handle this, with the appropriate FORWARD rule. That routing can be established manually or through the VPN server config, it depends on your requirements. If you want to look at this option, can you add your openvpn server configuration and the output of route -n to your post?
EDIT
To ensure the connection routes back over the VPN, you'll need a route to your LAN from the server. To add this manually on the MySQL Server:
route add -net 192.168.1.0/24 dev tun0 (if tun0 is your VPN client interface).
If it works, it's better to add this to your VPN client config:
route 192.168.1.0/24 (This will automatically create the route on connection, regardless of the tunnel interface or the PPP endpoint addresses being used)
A useful debugging tip:
tcpdump -i tun0 -qtln port 3306 on the server will show you the mysql traffic going through the VPN adaptors (client or server). You should be able to see where the connection handshaking is going awry.
Best Answer
I've based my setup on the following guide: Lans behind OpenVPN.
The first change needed was to enable the client-config-dir setting in my server's configuration
In that directory, for the site A VPN client I marked it as the internal owner of that route
Then, I switched to a subnet topology ( still not the default ), defined and pushed the internal routes to all the clients:
I specifically set a higher metric for the VPN route ( 1000 ) so that devices connected to that network directly do not use it. At least on my local workstation the default metrics are 100 for ethernet and 600 for wireless, so the VPN is used only if none of those are present.
Of course, ipv4 forwarding is enabled on the network devices.
With that being done, all is working as expected.