First of all: you won't be able to route traffic to 127.x.y.z anywhere other than the local machine (ok, it might even be possible, but you'd certainly break something else in the process...) so I'd recommend updating the apache config to also listen at the VPN IP (e.g. 10.8.0.1). If that's not an option, you could try one of the options at the end of my answer.
OpenVPN clients should already get a route to the server, in my example sth. like this:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.1 10.8.0.53 255.255.255.255 UGH 0 0 0 tun0
10.8.0.53 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
If you want additional routes pushed to the clients, use:
push "route 192.168.10.0 255.255.255.0"
(change the IP/netmask accordingly).
If you want your apache instance to be accessible by hostname (and not just at
http://10.8.0.1/), put this in every client's
or set up a DNS server (like dnsmasq <- make sure you disable the dhcp server) and push it to the clients (in your ovpn-conf):
push "dhcp-option DNS 10.8.0.1"
That should do the trick.
If you're unable to change the IPs apache's listening at, the following approaches come to my mind (but only use them as last resort):
SSH port forwarding: Instead of using OpenVPN (or any other VPN server), connect to your server using SSH:
ssh -L1234:localhost:80 user@servername
That way the apache instance on the server (listening only at
127.0.0.1:80) will be available at your client at
http://localhost:1234/. You'd have to do this on every client, therefore it's probably not suitable if you've got many of them.
But even then you could set up a dedicated ssh user without shell access and a public key for each client in
~/.ssh/authorized_keys. Keep in mind that the clients may be able to use this as a proxy to the internet or do some other stuff you might not want them to. So it's important to configure sshd correctly.
- some iptables magic (you'd have to NAT the traffic)
- some other user space port forwarding or a reverse proxy