Skip to content
If you're able to it might be worth temporarily trying static information and see if you still get the same problem (i.e. use the same reserved IP address, DNS servers, subnet mask, and router your DHCP server would normally give you, but set statically). This should be fine as a temporary setting - it's really just to test whether a DHCP response is causing the DNS change, or something else is the cause.
Cheers
James
-graham
(side note: it would be nice if when you bring up the details window it defaulted to the active connection if there was one, rather than just the first connection in the list)
66.x.x.x.
66.x.x.x.
with VPN i have:
83.x.x.x
83.x.x.x
4.2.2.1
with the manual setup and VPN i have:
83.x.x.x.
83.x.x.x.
4.2.2.1
66.x.x.x.
66.x.x.x.
-graham
Losing DNS server
Got a problem with Viscosity or need help? Ask here!
- Posts: 14
- Joined: Thu Nov 06, 2008 3:18 am
Post
by troymurray » Thu Nov 06, 2008 3:56 am
I'm having a strange issue that I can't pin down why it happens, and it only happens on occasion, but here is the problem. The DNS server that we use internally, and my system is set to use when I successfully connect to the SSL VPN, sometimes is forgotten by Mac OS X 10.5.5. This happened just this morning and I ran the following utilities to show what the result is, but I'm not sure why it's happening. After I'm connected for some period of time, sometime it's after the screen saver comes on, sometimes I'm just working away and it stops, DNS queries stop resolving using the internal DNS server.
When I display the etc/resolv.conf file the DNS server isn't listed:
When I display the etc/resolv.conf file the DNS server isn't listed:
Code: Select all
When I look at the order of how to resolve DNS, the internal DNS server isn't listed anymore:
troy-murrays-macbook-pro-15:etc murrayt5$ cat resolv.conf
nameserver 10.0.1.1
Code: Select all
However, after I disconnect, then re-connect to the SSL VPN the DNS server shows up again, as shown by showing my etc/resolve.conf file again
troy-murrays-macbook-pro-15:named murrayt5$ scutil --dns
DNS configuration
resolver #1
nameserver[0] : 10.0.1.1
order : 200000
resolver #2
domain : troymurray.members.mac.com.
options : pdns
timeout : 5
order : 150000
resolver #3
domain : local
options : mdns
timeout : 2
order : 300000
resolver #4
domain : 254.169.in-addr.arpa
options : mdns
timeout : 2
order : 300001
resolver #5
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300002
resolver #6
domain : 9.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300003
resolver #7
domain : a.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300004
resolver #8
domain : b.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300005
Code: Select all
as well as looking at the order for resolution
troy-murrays-macbook-pro-15:etc murrayt5$ cat resolv.conf
domain myprivatedomain.local
nameserver 192.168.192.4
Code: Select all
Any ideas? I'm sure this is kind of vague for an explanation.troy-murrays-macbook-pro-15:etc murrayt5$ scutil --dns
DNS configuration
resolver #1
domain : myprivatedomain.local
nameserver[0] : 192.168.192.4
order : 200000
resolver #2
domain : myprivatedomain.local
nameserver[0] : 192.168.192.4
order : 200000
resolver #3
domain : myid.members.mac.com.
options : pdns
timeout : 5
order : 150000
resolver #4
domain : local
options : mdns
timeout : 2
order : 300000
resolver #5
domain : 254.169.in-addr.arpa
options : mdns
timeout : 2
order : 300001
resolver #6
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300002
resolver #7
domain : 9.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300003
resolver #8
domain : a.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300004
resolver #9
domain : b.e.f.ip6.arpa
options : mdns
timeout : 2
order : 300005
--
Troy Murray
Troy Murray
Hi Troy,
I haven't been able to replicate this behaviour myself, although I have had another report of the same issue.
At this stage all I have is a theory as to what may be going on: your network interface is using DHCP, and a drop out (e.g. with wireless) or a DHCP lease expire (which will cause Mac OS X to re-ask for an IP, DNS addresses etc) is causing Mac OS X to overwrite the DNS servers set by Viscosity. I'm trying to validate this to see if this is really the case - it might be something completely different. If it is indeed the case, setting a static IP (rather than using DHCP) might theoretically avoid the issue.
You could also try ticking "Use alternate DNS support" under Preferences->Advanced to see if it helps. It would also be worth looking at the OpenVPN log in the Details window to see if it reveals anything.
Cheers
James
I haven't been able to replicate this behaviour myself, although I have had another report of the same issue.
At this stage all I have is a theory as to what may be going on: your network interface is using DHCP, and a drop out (e.g. with wireless) or a DHCP lease expire (which will cause Mac OS X to re-ask for an IP, DNS addresses etc) is causing Mac OS X to overwrite the DNS servers set by Viscosity. I'm trying to validate this to see if this is really the case - it might be something completely different. If it is indeed the case, setting a static IP (rather than using DHCP) might theoretically avoid the issue.
You could also try ticking "Use alternate DNS support" under Preferences->Advanced to see if it helps. It would also be worth looking at the OpenVPN log in the Details window to see if it reveals anything.
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: 14
- Joined: Thu Nov 06, 2008 3:18 am
Post
by troymurray » Fri Nov 07, 2008 1:45 am
James,
Thanks for the response. What's interesting is the DNS address that it has after this occurs, 10.x.x.x, that range is only used in the SSL VPN pool, no where else. Very strange. I can try the alternate DNS setting to see if it happens, just wish there was a way to trigger it to occur.
Thanks for the response. What's interesting is the DNS address that it has after this occurs, 10.x.x.x, that range is only used in the SSL VPN pool, no where else. Very strange. I can try the alternate DNS setting to see if it happens, just wish there was a way to trigger it to occur.
--
Troy Murray
Troy Murray
Hi guys,
I'm seeing this issue as well... running OS X 10.5.5 and the latest version of viscosity (though i saw it in the previous version as well which was the first version of viscosity that i have used).
The behavior i see is the following:
I connect to my OpenVPN server using viscosity.. everything works great. name servers are from my OPV host 83.x.x.x.x
After some period of time (shortest is an hour, often times its longer) the name servers for my local machine revert back to my ISPs name servers, 66.x.x.x.x.
Everything else works fine, ie. IP based connections, connections already established etc. name resolution does not work.
If i check something like whatsmyip.com to see what my IP looks like to the outside world it still shows it as going thru my OPV host (83.x.x.x)
If i disconnect via viscosity and reconnect everything is restored and works until the DNS is lost again.
I'm using DHCP via wireless but with a reserved address. I can't use a wired connection from my current location.
The other thing that might be an issue is that my internet connection is via satellite, so short dropouts or lost packets are not uncommon. Dont know if viscosity might fallback to other DNS or something if it tries to resolve a name and their is a failure.
I had a quick look thru the Viscosity logs and didn't see anything.
I'll try the alt. dns option to see if it helps. What exactly does that option do?
-g
I'm seeing this issue as well... running OS X 10.5.5 and the latest version of viscosity (though i saw it in the previous version as well which was the first version of viscosity that i have used).
The behavior i see is the following:
I connect to my OpenVPN server using viscosity.. everything works great. name servers are from my OPV host 83.x.x.x.x
After some period of time (shortest is an hour, often times its longer) the name servers for my local machine revert back to my ISPs name servers, 66.x.x.x.x.
Everything else works fine, ie. IP based connections, connections already established etc. name resolution does not work.
If i check something like whatsmyip.com to see what my IP looks like to the outside world it still shows it as going thru my OPV host (83.x.x.x)
If i disconnect via viscosity and reconnect everything is restored and works until the DNS is lost again.
I'm using DHCP via wireless but with a reserved address. I can't use a wired connection from my current location.
The other thing that might be an issue is that my internet connection is via satellite, so short dropouts or lost packets are not uncommon. Dont know if viscosity might fallback to other DNS or something if it tries to resolve a name and their is a failure.
I had a quick look thru the Viscosity logs and didn't see anything.
I'll try the alt. dns option to see if it helps. What exactly does that option do?
-g
10.x.x.x, that range is only used in the SSL VPN pool, no where else. Very strange.So 10.0.1.1 isn't your standard local DNS server that your Mac uses when not using VPN? If so, that is very strange! Are you using a tap based connection (rather than tun)? Could there be a DHCP server somewhere on the remote network specifying a DNS server of 10.0.1.1?
I'm using DHCP via wireless but with a reserved address.Thanks for jumping into the thread gfarrar.
If you're able to it might be worth temporarily trying static information and see if you still get the same problem (i.e. use the same reserved IP address, DNS servers, subnet mask, and router your DHCP server would normally give you, but set statically). This should be fine as a temporary setting - it's really just to test whether a DHCP response is causing the DNS change, or something else is the cause.
I'll try the alt. dns option to see if it helps. What exactly does that option do?Sounds good. I'm hoping that any DHCP servers don't override the VPN DNS servers with this option. A full explanation of this option is available in this thread (thanks to a well timed question by Troy).
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: 14
- Joined: Thu Nov 06, 2008 3:18 am
Post
by troymurray » Fri Nov 07, 2008 2:38 am
James,
Actually the VPN pool that I'm in is 10.242.2.x/24, so the 10.0.1.1 address isn't even in my range let alone reachable. The campus network here uses 35.8.x.x - 35.15.x.x for the network range. I have no idea where 10.0.1.1 would even come from.
Actually the VPN pool that I'm in is 10.242.2.x/24, so the 10.0.1.1 address isn't even in my range let alone reachable. The campus network here uses 35.8.x.x - 35.15.x.x for the network range. I have no idea where 10.0.1.1 would even come from.
--
Troy Murray
Troy Murray
- Posts: 14
- Joined: Thu Nov 06, 2008 3:18 am
Post
by troymurray » Fri Nov 07, 2008 2:40 am
James wrote:Mine is set to "tun", but I'm not sure what that means and how it differs from "tap", guess I need to spend some time reading up.Are you using a tap based connection (rather than tun)?
--
Troy Murray
Troy Murray
James wrote: You could also try ticking "Use alternate DNS support" under Preferences->Advanced to see if it helps. It would also be worth looking at the OpenVPN log in the Details window to see if it reveals anything.When i set the "Use alternate DNS support" option on, my DNS servers don't update at all when i connect to the VPN (i.e. they stay set as my ISP servers.. 66.x.x.x)
-graham
(side note: it would be nice if when you bring up the details window it defaulted to the active connection if there was one, rather than just the first connection in the list)
James wrote: Thanks for jumping into the thread gfarrar.Trying this out now.. FWIW, i noticed that using this method the DNS servers from my VPN connection are added to, rather than replacing the DNS servers when i use DHCP. so for example using DHCP w/o VPN, i have DNS servers like:
If you're able to it might be worth temporarily trying static information and see if you still get the same problem (i.e. use the same reserved IP address, DNS servers, subnet mask, and router your DHCP server would normally give you, but set statically). This should be fine as a temporary setting - it's really just to test whether a DHCP response is causing the DNS change, or something else is the cause.
66.x.x.x.
66.x.x.x.
with VPN i have:
83.x.x.x
83.x.x.x
4.2.2.1
with the manual setup and VPN i have:
83.x.x.x.
83.x.x.x.
4.2.2.1
66.x.x.x.
66.x.x.x.
-graham