0

I have installed OpenVPN on my server on which I also run git and web server. My initial idea before I got into installing was to be able to enable visiting of some websites only to VPN clients and to allow access to git's SSH only to them. I thought that I will only allow access to ports from VPS's local IPs - 10.254.1.0/24, but I figured out that package seems to be forwarded with my actual IP, not the IP from VPN. My current rule for prerouting from tun interface (I'm using UFW and this is part of iptables' rule which resides in ufw's before.rules):

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.254.1.0/24 -o eth0 -j MASQUERADE
COMMIT

I don't quite understand why is client's actual IP assigned to the packet which is sent through VPN, I would rather expect that this packet would be sent from VPN's network. I was thinking about solution for this and the only idea I got was to install OpenVPN on my second server and connect from it. However, the reason I posted this question is that I would more prefer to do this from current server where I already have OpenVPN installed. Any suggestion is welcomed.

  • What's the routing table on the vpn client? – GnP Aug 31 '16 at 23:16
  • I don't have any special rules for routing in OpenVPN configs, except the push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 8.8.8.8" push "dhcp-option DNS 8.8.4.4" (which are in server config). Routing table from client is here: pastebin.com/CK0zDHWU – user1257255 Sep 1 '16 at 5:53
  • Can you try to use this masquerading rule instead? -A POSTROUTING -s 10.254.1.0/24 -o eth0 ! -d <server-ip> -j MASQUERADE – maxf Sep 1 '16 at 9:13
  • I don't see a static route for the vpn server there, does client-server communication within the tunnel work? Also on the server is eth0 the interface to the rest of the world? – GnP Sep 1 '16 at 14:38
  • Client-server communication within tunnel work, server is also available through 10.254.1.1, but it also doesn't accept connection if I try to connect to its VPN IP instead of domain. eth0 is the interface to the rest of the world, yes. – user1257255 Sep 1 '16 at 15:21
1

I assume* you're trying to reach the vpn server at it's public address and expecting this connection goes through the tunnel.

This won't happen, your client needs to connect to your vpn server over the public network to establish and maintain the tunnel.

You have several options, the simpler of which seems to be to setup a sort of split-horizon DNS using Dnsmasq.

  1. Install Dnsmasq on the server
  2. Set a /etc/hosts entry pointing your server's name to the vpn address
  3. Instead of pushing DNS 8.8.8.8 for the clients push DNS 10.254.1.1

That way your clients will resolve you server name internally while they're connected to the vpn.

If you want the server itself to keep resolving its own name to the public address use an additional hosts file for Dnsmasq instead of the system-wide one at /etc/hosts.


*: if the assumption is wrong the whole answer is useless so please let me know :-)

  • I didn't try this yet, but I think you are correct. Currently if I ping my domain from VPN client, this ping will seems to travel through eth0 and then reach its destination (as actual IP address). If I ping 10.254.1.1 then the server seems to be pinged directly. I suppose this because ping to 10.254.1.1 response in around 100 ms less. Just a question regarding the hosts file - if I just add 10.254.1.1 mydomain.tld sub.mydomain.tld this should not have any impact on my services? I think that problem could be because there is already an entry for 127.0.0.1 mydomain.tld ... – user1257255 Sep 2 '16 at 13:41
  • @user1257255 it shouldn't cause any trouble. If it does you can use a separate hosts file as mentioned. – GnP Sep 2 '16 at 13:51
  • Last question before I accept answer is about the same thing I asked before. I'm using Ubuntu Server 16.04 and in /etc/hosts there already is: 127.0.0.1 localhost.localdomain localhost # Auto-generated hostname. Please do not remove this comment. <actual-ip-address> mydomain.tld mydomain In case that I append 10.254.1.1 mydomain.tld sub.mydomain.tld, sub.mydomain.tld is correctly pointing to 10.254.1.1 meanwhile mydomain.tld is pointing to actual server address. Is there an option to also override this one and could this cause any trouble because this entry is generated by OS? – user1257255 Sep 3 '16 at 13:00
  • @user1257255 replacing it shouldn't cause any trouble, it's only visible to the server itself (which can always reach the vpn interface) and the clients when they're connected (can reach the interface). In some situations it can cause trouble for MTAs, but if that's the case it's easy to solve with an additional hosts file specific to Dnsmasq. – GnP Sep 3 '16 at 13:05
  • Thank you very much! I created separate hosts file and now everything works as expected. – user1257255 Sep 5 '16 at 17:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.