0

I set up an OpenVPN server on a Debian 9 server, and everything seems to work fine: I can access Internet through that VPN. However, I figured out that any traffic targeting the server is still using either eth0 or wlan0 instead of tun0. For example, if I am on a local network that does not allow ICMP:

ping google.com will work as expected (using tun0as output interface)

ping myvpn.com (if myvpn.com is my vpn server) will not work, as it uses eth0 or wlan0 as output interface and so is blocked by the network firewall.

I looked at the routes and found that when connecting, OpenVPN client is adding an entry in the routing table: 1.2.3.4 via 10.0.0.1 dev wlp7s0 proto static metric 600 (where 1.2.3.4 is my vpn public IP)

I understand what this route is for: when OpenVPN client send packets to the OpenVPN server to be then rerouted to Internet, it has to send them through a physical interface. However, I would like that when I ping or SSH to the server, packets are send through the tun0 interface.

Is there an option to give to OpenVPN client or maybe an iptables rule so that only OpenVPN generated packets are sent through a physical interface?

EDIT: Everything is working fine for outgoing traffic: it goes all through the VPN, except for the traffic that has for destination the server itself. I think the problem may be on the client side, where the route to the server is being added Here is server config file:

port 443
proto tcp
dev tun

ca /path/to/ca.crt
cert /path/to/server.crt
key /path/to/server.key
dh /path/to/dh.pem

server 10.8.0.0 255.255.255.0
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

push "redirect-gateway def1 bypass-dhcp"
push "route 10.8.8.0 255.255.255.0"

I tried to modify this line:

push "redirect-gateway def1 bypass-dhcp"

to this:

push "redirect-gateway autolocal def1 bypass-dhcp"

as suggested in answers, but result is still the same: I can ping google.com but not my VPN public IP

gagarine
  • 3
  • 4
  • if you want to reach the server through the VPN, why do you ping myvpn.com and not 10.8.0.1? – Luca Gibelli Mar 27 '18 at 21:05
  • it is mostly for convenience: if I have other services running on the same server and I want to reach them, using 10.8.0.1 force me to have two configurations on client side: one when I'm connected to the VPN and one when I'm not – gagarine Mar 28 '18 at 13:29
  • @AndrewSchulman I thought that as well, but that's not the case. OP wants to have ssh traffic with source == VPN clients and destination == the public IP of the OpenVPN server itself go through the VPN. This is not about routing traffic from clients to the Internet through the VPN. It's only about traffic to the VPN server itself. – Luca Gibelli Mar 30 '18 at 10:13
  • @gagarine does my answer solve your problem? – Luca Gibelli Mar 30 '18 at 10:14

1 Answers1

0

The easiest way to do it is to add an iptables rule on the client to redirect outgoing traffic with destination myvpn.com:22 to the vpn endpoint at 10.8.0.1

 sysctl net.ipv4.ip_forward=1
 iptables -t nat -A PREROUTING -p tcp -d myvpn.com --dport 22 -j DNAT --to-destination 10.8.0.1:22
 iptables -t nat -A POSTROUTING -d 10.8.0.1 -p tcp --dport 22 -j SNAT --to myvpn.com:22
 iptables -A FORWARD -d 10.8.0.1 -p tcp --dport 22 -j ACCEPT

The SNAT rule is needed to receive replies: without it, packets would be discarded because the source IP is not what we expect (10.8.0.1 instead of myvpn.com).

I don't think there is a way to enforce this behaviour by pushing some options from the openvpn server to the clients. You need to add these rules manually to your clients.

Luca Gibelli
  • 2,611
  • 1
  • 21
  • 29
  • Thank you, that is working! I will add this in a script that is executed whenever the connection to the VPN is up – gagarine Mar 31 '18 at 11:55