1

I would like to use a my linux workstation as VPN gateway for my local network. The same workstation is being used as webserver. When I connect the workstation to VPN it is not possible anymore to reach this webserver from an outside network.

My setup is as follows:

ISP router - ip 192.168.0.1 (default gateway, port mapping enabled to use non standard public port)

Linux workstation - fixed ip 192.168.0.20 (dhcp server as my router does not allow to change the gateway address, openvpn, apache, dns server)

output of "ip route show"

0.0.0.0/1 via 10.8.3.1 dev tun0 
default via 192.168.0.1 dev eth0 src 192.168.0.20 metric 202 
10.8.3.0/24 dev tun0 proto kernel scope link src 10.8.3.12 
37.120.143.221 via 192.168.0.1 dev eth0 (VPN external IP)
128.0.0.0/1 via 10.8.3.1 dev tun0 
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.20 metric 202 

Configuration as follows:

net.ipv4.ip_forward = 1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p icmp -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun0 -j ACCEPT
-A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

One thing I notice is that when VPN is enabled on the workstation, my ISP router does not list the correct local ip address for my linux workstation in the list of connected clients. Sometimes it is correct, but sometimes it just looks like a random IP.

If I add the following route: EXTERNAL_IP via 192.168.0.1 dev eth0 (where EXTERNAL_IP is WAN ip) then I can reach the webserver on the local network, but still not from another network.

1 Answer 1

0

There is nothing wrong with your setup, the mistake lies in your routing.

If your server works both as a webserver and as a VPN client for a remote server, any user trying to access the webserver will receive a reply from the remote VPN server (not directly from the webserver) because the routing table of your local server instructs it to route everything thru the remote OpenVPN server. Any machine sending a query to site A but receiving a reply from B automatically discards the reply, for obvious security reasons. Hence the webserver becomes unaccessible.

There are many, many ways to solve your problem. My favorite one would be to leave the webserver untouched, and move the OpenVPN client to a Linux container hosted on the very same server, then change your router configuration to your DHCP/dnsmasq (whatever) server to route all LAN communication via the Linux container. It is much easier than it sounds.

Another possibility is to set up two routing tables, leaving the main one for the OpenVPN clients, while setting up the second one as identical to the routing table that you have when the VPN is not active, and then instructing your kernel to route all traffic originating from the server (itself!) thru this second routing table. The remaining traffic (that which originates in your LAN, and which you want routed thru the OpenVPN) will by default use the main routing table.

This too is quite easy to do, you can find here an excellent, very brief introduction to Linux policy (or source) routing.

Or you could decide to host your webserver on the very same machine which hosts your OpenVPN server, which would also solve your problem. In this case, the simplest thing would be to mirror your local web site on the remote server, so that you can do any change locally.

The choice is really all yours.

2
  • Thank you for your response. I will try the approach with 2 routing tables. Running a Linux container for my OpenVPN client seems a little demanding for my linux workstation and I am not the administrator of the OpenVPN server so I can't move my webserver there.
    – phalkone
    Commented Sep 23, 2019 at 20:06
  • Based on your suggestion to use policy routing, I have followed the guide at osric.com/chris/accidental-developer/2019/03/… and marked incoming packets on my eth0 interface and created a separate routing table. It is working now. Thanks a lot for your suggestion.
    – phalkone
    Commented Sep 23, 2019 at 21:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .