DNS resolution for private net connected through VPN

Question

Level 1

13 points

DNS resolution for private net connected through VPN

Hi all,

I've set up a VPN connection (from a private subnet into a private subnet) to a MacMini SLS. The connection works fine.
The DNS server on that SLS also works as it should.
On the advanced tab in network settings for the VPN connection I've entered the domain name (domain.intra) on the «VPN on Demand tab» and I've also entered the DNS Server address and Search Domain on the «DNS» tab.
When I connect to the VPN and run a dig command for one of the servers on the other side, my system (10.6.4) still asks my local DNS server and name resolution fails.
I don't want to route all traffic over the VPN connection, so I did not check the «Send all traffic over VPN connection» setting.
Here are some log messages:
06.09.10 11:30:43 pppd[1332] IPSec connection established
06.09.10 11:30:44 pppd[1332] L2TP connection established.
06.09.10 11:30:44 pppd[1332] Connect: ppp0 <--> socket[34:18]
06.09.10 11:30:45 pppd[1332] local IP address 192.168.200.246
06.09.10 11:30:45 pppd[1332] remote IP address 192.168.200.251
06.09.10 11:30:45 pppd[1332] primary DNS address 192.168.200.251
06.09.10 11:30:45 pppd[1332] secondary DNS address 192.168.200.251

So it looks like the DNS server gets added somehow. Why isn't it working? And why wouldn't the system automatically connect through that VPN when I try to access an address inside domain.intra? Isn't that what the VPN on Demand settings are for?

Thanks for your suggestions, Rado

Macbook Pro (Original) 17", MacMini SLS (2010), Mac OS X (10.6.4)

Posted on Sep 6, 2010 2:37 AM

Reply

Answer 1

Sep 6, 2010 2:50 AM in response to Knorke

Mac OS X uses a DNS search strategy that supports multiple DNS client configurations. Each DNS client
has its own set of nameserver addresses and its own set of operational parameters. Each client can
perform DNS queries and searches independent of other clients. Each client has a symbolic name which
is of the same format as a domain name, e.g. "apple.com". A special meta-client, known as the "Super"
DNS client acts as a router for DNS queries. The Super client chooses among all available clients by
finding a best match between the domain name given in a query and the names of all known clients.

Queries for qualified names are sent using a client configuration that best matches the domain name
given in the query. For example, if there is a client named "apple.com", a search for "www.apple.com"
would use the resolver configuration specified for that client. The matching algorithm chooses the
client with the maximum number of matching domain components. For example, if there are clients named
"a.b.c", and "b.c", a search for "x.a.b.c" would use the "a.b.c" resolver configuration, while a search
for "x.y.b.c" would use the "b.c" client. If there are no matches, the configuration settings in the
default client, generally corresponding to the /etc/resolv.conf file or to the "primary" DNS configura-tion configuration
tion on the system are used for the query.

If multiple clients are available for the same domain name, the clients ordered according to a
search_order value (see above). Queries are sent to these resolvers in sequence by ascending value of
search_order.

The configuration for a particular client may be read from a file having the format described in this
man page. These are at present located by the system in the /etc/resolv.conf file and in the files
found in the /etc/resolver directory. However, client configurations are not limited to file storage.
The implementation of the DNS multi-client search strategy may also locate client configuratins in
other data sources, such as the System Configuration Database. Users of the DNS system should make no
assumptions about the source of the configuration data.

Reply

Answer 2

Sep 6, 2010 2:58 AM in response to Knorke

i would look at your VPN configuration. When the VPN is setup you are being given a DNS IP address along with the other DHCP lease stuff . I would suggest you go and ensure the information given out in the lease is correct.

Reply

Answer 3

Knorke Author

Level 1

13 points

Sep 6, 2010 3:11 AM in response to Killerdll

Hi Killerdll, thanks for your posts.
As far as I can understand from your man page it should work. When I connect the DNS server address shown in the advanced tab is correct (see pic here http://dl.dropbox.com/u/424611/VPN_conn.png). So the «Super» DNS client should use that DNS server for resolving e.g. onkel.agapi.intra.
But it does not. Here is what dig says:
#dig onkel.agapi.intra

; <<>> DiG 9.6.0-APPLE-P2 <<>> onkel.agapi.intra
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21308
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;onkel.agapi.intra. IN A

;; Query time: 44 msec
;; SERVER: 192.168.1.112#53(192.168.1.112)
;; WHEN: Mon Sep 6 12:03:46 2010
;; MSG SIZE rcvd: 35

192.168.1.112 is my local DNS server which does not know anything about agapi.intra.

Why isn't it working?

Reply

Answer 4

Knorke Author

Level 1

13 points

Sep 7, 2010 1:13 AM in response to Knorke

Hi, I've made some progress.
When I run «scutil --dns» in a terminal, I'll normally get this:
{quote:title=no VPN:}scutil --dns
DNS configuration

resolver #1
domain : cocon.int
nameserver[0] : 192.168.1.112
order : 200000
{quote}
Scutil command after connecting to the VPN:
{quote:title=VPN on:}scutil --dns
DNS configuration

resolver #1
domain : cocon.int
search domain[0] : agapi.intra
search domain[1] : cocon.int
nameserver[0] : 192.168.1.112
order : 200000

resolver #2
domain : agapi.intra
nameserver[0] : 192.168.200.251
nameserver[1] : 192.168.200.251
order : 100000
{quote}

For some reason OSX adds the search domain agapi.intra to the first resolver - which is my local DNS server who doesn't know anything about agapi.intra. The second resolver added by the network process would work great if the agapi.intra domain hadn't been added to the first resolver.
How can I prevent that?

Reply