2

When you connect to openvpn from network manager. it does not encrypt dns requests through vpn, the result is that ubuntu uses local goverment dns results.

  • I have developed method with NetworkManager dispatcher and it works for 16.04 LTS. You can test it on 18.04 LTS. – N0rbert Jun 11 '18 at 11:18
  • @N0rbert Not solved the problem. This is the profile : ufile.io/l5cvt – M-E-Activist Jun 11 '18 at 18:01
  • @N0rbert adding these lines script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-conf and running via openvpn command solve it, but I want to use it by network manager, but even sudo nmcli did not solve problem – M-E-Activist Jun 11 '18 at 23:09
0

If you have set up your own VPN, you can modify the following line in the openvpn configuration file.

push "redirect-gateway def1 bypass-dhcp bypass-dns"

Change that to

push "redirect-gateway def1 bypass-dhcp"

and change the default configuration:

push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

to

push "dhcp-option DNS 10.8.0.1"

Assuming 10.8.0.1 is the gateway you setup for your vpn clients. Note: Normally you don't want DHCP to go over VPN, if you do, remove the bypass-dhcp also.

Also make sure your server can handle the traffic by adding the following to the firewall rules.

iptables -v -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

If those doesn't fix not your problem, then you need to look at your routing table on your client side to ensure that the gateway route over 10.8.0.1 has lower metric over the gateway configured on client machine (typically 19.168.0.1 or something). You can modify increase the non-vpn gateway to a higher number, lower metric have higher routing priority.

On your client machine after connected to the VPN, check the routing metric.

ip route
default via 10.8.0.1 dev tun0 proto static metric 50 
default via 192.168.0.1 dev enx00 proto dhcp metric 100 
default via 192.168.0.1 dev wlps proto dhcp metric 600 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.4 metric 50 
100.77.34.23 via 192.168.0.1 dev enx00 proto static metric 100
....

As you can see, 10.8.0.1 tunnel have the lowest metric and hence will be tried first. The 192.168.0.1 of the local ISP on ethernet interface will be tried next, and so on.

  • My problem is only when you connecting from the network manager. It appears that it change DNS but send dns request unencrypted (not through vpn), which cause the government changes the result to its local DNS server (sink) – M-E-Activist Jun 14 '18 at 19:38
  • Have you check your routing priority, the 10.8.0.1 dateway needs to have lower metric and also that the gateway can process the dns request (hence the masquerade rule). Try "ip route" to check the metric, it will only traverse down the route when it failed to match or cannot resolve. – Bernard Wei Jun 14 '18 at 21:17

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.