network manager openvpn use local dns
Clash Royale CLAN TAG#URR8PPP up vote
1
down vote
favorite
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.
openvpn
asked Jun 11 at 2:03
M-E-Activist
63
add a comment |Â
up vote
1
down vote
favorite
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.
openvpn
asked Jun 11 at 2:03
M-E-Activist
63
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 at 11:18
@N0rbert Not solved the problem. This is the profile : ufile.io/l5cvt
– M-E-Activist
Jun 11 at 18:01
@N0rbert adding these linesscript-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-confand running via openvpn command solve it, but I want to use it by network manager, but evensudo nmclidid not solve problem
– M-E-Activist
Jun 11 at 23:09
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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.
openvpn
asked Jun 11 at 2:03
M-E-Activist
63
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.
openvpn
asked Jun 11 at 2:03
M-E-Activist
63
edited Jun 14 at 19:19
asked Jun 11 at 2:03
M-E-Activist
63
asked Jun 11 at 2:03
M-E-Activist
63
asked Jun 11 at 2:03
M-E-Activist
63
63
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 at 11:18
@N0rbert Not solved the problem. This is the profile : ufile.io/l5cvt
– M-E-Activist
Jun 11 at 18:01
@N0rbert adding these linesscript-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-confand running via openvpn command solve it, but I want to use it by network manager, but evensudo nmclidid not solve problem
– M-E-Activist
Jun 11 at 23:09
add a comment |Â
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 at 11:18
@N0rbert Not solved the problem. This is the profile : ufile.io/l5cvt
– M-E-Activist
Jun 11 at 18:01
@N0rbert adding these linesscript-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-confand running via openvpn command solve it, but I want to use it by network manager, but evensudo nmclidid not solve problem
– M-E-Activist
Jun 11 at 23:09
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 at 11:18
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 at 11:18
@N0rbert Not solved the problem. This is the profile : ufile.io/l5cvt
– M-E-Activist
Jun 11 at 18:01
@N0rbert Not solved the problem. This is the profile : ufile.io/l5cvt
– M-E-Activist
Jun 11 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 at 23:09
@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 at 23:09
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
0
down vote
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.
answered Jun 13 at 22:01
Bernard Wei
677313
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 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 at 21:17
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
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.
answered Jun 13 at 22:01
Bernard Wei
677313
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 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 at 21:17
add a comment |Â
up vote
0
down vote
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.
answered Jun 13 at 22:01
Bernard Wei
677313
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 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 at 21:17
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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.
answered Jun 13 at 22:01
Bernard Wei
677313
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.
answered Jun 13 at 22:01
Bernard Wei
677313
edited Jun 14 at 21:21
answered Jun 13 at 22:01
Bernard Wei
677313
answered Jun 13 at 22:01
Bernard Wei
677313
answered Jun 13 at 22:01
Bernard Wei
677313
677313
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 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 at 21:17
add a comment |Â
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 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 at 21:17
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 at 19:38
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 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 at 21:17
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 at 21:17
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1045445%2fnetwork-manager-openvpn-use-local-dns%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e)
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom))
StackExchange.using('gps', function() StackExchange.gps.track('embedded_signup_form.view', location: 'question_page' ); );
$window.unbind('scroll', onScroll);
;
$window.on('scroll', onScroll);
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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 at 11:18
@N0rbert Not solved the problem. This is the profile : ufile.io/l5cvt
– M-E-Activist
Jun 11 at 18:01
@N0rbert adding these lines
script-security 2 up /etc/openvpn/update-resolv-conf down /etc/openvpn/update-resolv-confand running via openvpn command solve it, but I want to use it by network manager, but evensudo nmclidid not solve problem– M-E-Activist
Jun 11 at 23:09