Skip to content
Closing VPN connection does not reset DNS
Got a problem with Viscosity or need help? Ask here!
- Posts: 8
- Joined: Tue Nov 25, 2008 6:35 pm
Closing a VPN connection in Viscosity does not reset the DNS settings - or at least not all of them (see "log" below).
-Paul
Code: Select all
For me the only remedy seems to be to activate "Use alternate DNS support". However, I know that there must be something wrong with my installation/configuration because Viscosity is supposed to reset DNS settings.===============================================================================
== Regular DHCP ===============================================================
===============================================================================
ladytom:~ marcelstoer$ scutil --dns
DNS configuration
resolver #1
nameserver[0] : 138.188.101.186
nameserver[1] : 138.188.101.189
order : 200000
resolver #2
nameserver[0] : 138.188.101.186
nameserver[1] : 138.188.101.189
order : 100000
resolver #3
domain : local
options : mdns
timeout : 2
order : 300000
resolver #4
domain : 254.169.in-addr.arpa
options : mdns
timeout : 2
order : 300001
...
===============================================================================
== Viscosity VPN ==============================================================
===============================================================================
ladytom:~ marcelstoer$ scutil --dns
DNS configuration
resolver #1
domain : viscosity.default.search.domain
nameserver[0] : 172.17.1.111
nameserver[1] : 172.17.0.111
order : 200000
resolver #2
domain : local
options : mdns
timeout : 2
order : 300000
resolver #3
domain : 254.169.in-addr.arpa
options : mdns
timeout : 2
order : 300001
resolver #4
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300002
...
===============================================================================
== Disconnecting Viscosity VPN ================================================
===============================================================================
ladytom:~ marcelstoer$ scutil --dns
DNS configuration
resolver #1
resolver #2
domain : local
options : mdns
timeout : 2
order : 300000
resolver #3
domain : 254.169.in-addr.arpa
options : mdns
timeout : 2
order : 300001
resolver #4
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300002
...
-Paul
Hi Paul,
That is certainly a little odd - not something I have seen before. Try checking the "/tmp" directory on your computer while connected. If everything is functioning correctly Viscosity should write your original DNS settings to a temporary file (e.g. "openvpn_dns_tun0") while you are connected. When you disconnect this file will be read and your settings written back. It's possible that if Viscosity is unable to create this file, or it is empty, Viscosity won't have anything to write back. If the file is always there, even while you're disconnected, try deleting it.
There is nothing wrong using the "Use alternate DNS support" option - in fact it is the better way of setting DNS servers under Leopard. The only reason why it is not the default option as some applications (such as VMWare) expect the legacy technique to be used, and so may not correctly recognise the newer technique.
Cheers
James
That is certainly a little odd - not something I have seen before. Try checking the "/tmp" directory on your computer while connected. If everything is functioning correctly Viscosity should write your original DNS settings to a temporary file (e.g. "openvpn_dns_tun0") while you are connected. When you disconnect this file will be read and your settings written back. It's possible that if Viscosity is unable to create this file, or it is empty, Viscosity won't have anything to write back. If the file is always there, even while you're disconnected, try deleting it.
There is nothing wrong using the "Use alternate DNS support" option - in fact it is the better way of setting DNS servers under Leopard. The only reason why it is not the default option as some applications (such as VMWare) expect the legacy technique to be used, and so may not correctly recognise the newer technique.
Cheers
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
- Posts: 8
- Joined: Tue Nov 25, 2008 6:35 pm
Hi James,
Thanks for the insight into the DNS (re)setting mechanism.
I just double-checked the DNS behavior again. I works as expected over AirPort WiFi, but the described behavior occurred while using a HSDPA 3G USB modem. Both connections use DHCP to set the DNS entries in OS X. Since I don't have the HSDPA modem here right now I can't investigate any further.
I'll get back to this forum if I need more help or if I discover something relevant regarding this issue.
-Paul
Thanks for the insight into the DNS (re)setting mechanism.
I just double-checked the DNS behavior again. I works as expected over AirPort WiFi, but the described behavior occurred while using a HSDPA 3G USB modem. Both connections use DHCP to set the DNS entries in OS X. Since I don't have the HSDPA modem here right now I can't investigate any further.
I'll get back to this forum if I need more help or if I discover something relevant regarding this issue.
-Paul
3 posts
Page 1 of 1