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.
The first three lines refer to 10.180.x.x when I think you meant 10.8.x.x ?
If so, the line iptables -A FORWARD -s 10.180.0.10 -d 10.8.0.6 -j ACCEPT is unnecessary.
Otherwise looks good.
Best Answer
Should do the trick... unless you are nat-ing first.
You could even add a
-i tun0or something, to limit on the interface name.