bind-address-ipv4 worked for me.
I established the tunnel and determined the gateway using the system log interface. My log for the Tun11 interface and gateway assignment looks like the following:
Code:
openvpn[2902]: updown.sh tun11 1500 1558 10.10.12.18 10.10.12.17 init
Then SSH into the box and perform the Transmission config change.
Code:
/opt/etc/init.d/S88transmission stop
nano -w /opt/etc/transmission/settings.json
Change the value for the Binding-
Code:
"bind-address-ipv4": "10.10.12.18",
Save the config. Restart the service
Code:
/opt/etc/init.d/S88transmission start
Leave the SSH window up and test for VPN connections. I am using the default port. I expect to see Nat'd traffic 10.X.X.X via port 51413 to external hosts.
Code:
cat /proc/net/ip_conntrack
Fire up transmission and compare the ip's list for a running torrent against the connections listed. They should be the same.
A lot of traffic in with my VPN traffic so if all looks ok (no lan ips with torrent destinations) then we can look at just the torrent traffic.
Code:
cat /proc/net/ip_conntrack | grep 51413
Now testing. Turn off VPN. You will notice on the transmission GUI that connections will drop off. Re-run the ip_conntrack command. These connects should start ceasing as well but more importantly they do not deviate from the Nat'd 10.#.#.# space and stay away from the local lan or non-vpn tunneled traffic.
Turn VPN back on and go back to you transmission GUI. Your external connections will start to slowly reconnect.
My tunnel has been very reliable but if that should change then a CRON script would be in order to verify the TUN11 up state to reconnect.