Port forward from LAN to an OpenVPN client (iptables?)

Question

I have a OpenVPN server running in a LAN (locally addressable at 192.168.1.12) and I'd like to forward requests to it from other devices on the LAN, over just port 3000, to one of the VPN clients. (10.8.0.6)

My end result is for 192.168.x.x devices to be able to reach a web server via typing 192.168.1.12:3000 into a browser, but actually be communicating with 10.8.0.6:3000.

ip forwarding is enabled on the vpn server.

(these modified attempts from other questions don't seem to work)

iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 3000 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -p tcp -d 10.8.0.6 --dport 3000 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Answer 1

Something similar can be achieved by adding a "static route" to your computers in the LAN which tells them where they can find the VPN clients.

LAN Clients

---

For example you could add a route to a Linux machine in your LAN like this:

(sudo) ip route add 10.8.0.0/24 via 192.168.1.12

On Windows the same can be achieved like this:

route add 10.8.0.0 mask 255.255.255.0 192.168.1.12

(If using Windows consider using the -p option with route to make the route persistent.

OpenVPN Server

---

Obviously your VPN clients also have to know about your LAN, which can be achieved by adding this to your OpenVPN server.conf:

push "route 192.168.1.0 255.255.255.0"

(Assuming that your LAN's netmask is /24 )

Now if you did all the above you can just access mentioned webserver like this: http://10.8.0.6:3000

Answer 2

Turns out... nothing was wrong with my initial iptables rule. Although only the first one was needed!

Answer 3

You can do the same without any iptables rules involved using SSH tunneling. Run following command on your OpenVPN server:

$ ssh -L 3000:10.8.0.6:3000 root@localhost &

After that if you'll open http://192.168.1.12:3000 and it will be forwarded to the 10.8.0.6:3000

Actual SSH connection will be running in the background and you'll need to run the command again after rebooting the server or occasionally dropping the connection.

Take a look here for more examples of SSH tunneling, it may be extremely useful in cases like that.