<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<font face="Monaco" class="">I continue to struggle with DNS name resolution and the StrongSwan Mac app. As shown by scutil below, the Mac app successfully installs the DNS server’s IP address into the PrimaryService service but DNS resolution still does not
use the DNS server IP sent to the initiator.<br class="">
<br class="">
Out of curiosity, why is the DNS server added to the PrimaryService store State:/Network/Service/97E8D482-1E2D-4743-B18D-FCA53A7151A7/DNS instead of State:/Network/Global/DNS where the System Preferences->Network configured servers are stored? Also, is there
any way to associate a search domain with the DNS server sent by the VPN gateway?<br class="">
<br class="">
Background: the DNS server behind the VPN gateway is 10.8.65.164 and it resolves addresses in the *.cazena.internal domain. When the IPsec tunnel is up, 10.8.65.164 is reachable via ICMP.<br class="">
<br class="">
Configuration: strongSwan OS X app version 5.2.2 (1) on OS X Yosemite v10.10.2 connecting to a StrongSwan version 5.2.2 gateway on Centos 6.6.<br class="">
<br class="">
<br class="">
Here’s the state of the Mac’s DNS configuration prior to connecting:<br class="">
<br class="">
$ scutil --dns<br class="">
DNS configuration<br class="">
<br class="">
resolver #1<br class="">
nameserver[0] : 8.8.8.8<br class="">
nameserver[1] : 8.8.4.4<br class="">
flags : Request A records<br class="">
reach : Reachable<br class="">
order : 5000<br class="">
<br class="">
DNS configuration (for scoped queries)<br class="">
<br class="">
resolver #1<br class="">
nameserver[0] : 8.8.8.8<br class="">
nameserver[1] : 8.8.4.4<br class="">
if_index : 4 (en3)<br class="">
flags : Scoped, Request A records<br class="">
reach : Reachable<br class="">
order : 5000<br class="">
$ scutil<br class="">
> get State:/Network/Global/IPv4<br class="">
> d.show<br class="">
<dictionary> {<br class="">
PrimaryInterface : en3<br class="">
PrimaryService : 97E8D482-1E2D-4743-B18D-FCA53A7151A7<br class="">
Router : 10.0.1.1<br class="">
}<br class="">
> get State:/Network/Service/97E8D482-1E2D-4743-B18D-FCA53A7151A7/DNS<br class="">
> d.show<br class="">
<dictionary> {<br class="">
ServerAddresses : <array> {<br class="">
}<br class="">
}<br class="">
> quit</font>
<div class=""><font face="Monaco" class=""><br class="">
</font></div>
<div class=""><font face="Monaco" class=""><br class="">
</font></div>
<div class=""><font face="Monaco" class="">The DNS server to be added is not reachable (tunnel down):</font></div>
<div class=""><font face="Monaco" class=""><br class="">
$ ping 10.8.65.164<br class="">
PING 10.8.65.164 (10.8.65.164): 56 data bytes<br class="">
Request timeout for icmp_seq 0<br class="">
^C<br class="">
--- 10.8.65.164 ping statistics ---<br class="">
2 packets transmitted, 0 packets received, 100.0% packet loss<br class="">
<br class="">
<br class="">
<br class="">
When connecting to the VPN gateway, the Mac app log shows:<br class="">
<br class="">
handling UNITY_SPLIT_INCLUDE attribute failed<br class="">
handling UNITY_LOCAL_LAN attribute failed<br class="">
installing 10.8.65.164 as DNS server<br class="">
handling UNITY_DEF_DOMAIN attribute failed<br class="">
installing 10.8.65.164 as DNS server<br class="">
<br class="">
<br class="">
The insertion of the DNS server’s IP (twice) is confirmed by scutil:<br class="">
<br class="">
$ scutil<br class="">
> get State:/Network/Global/IPv4<br class="">
> d.show<br class="">
<dictionary> {<br class="">
PrimaryInterface : en3<br class="">
PrimaryService : 97E8D482-1E2D-4743-B18D-FCA53A7151A7<br class="">
Router : 10.0.1.1<br class="">
}<br class="">
> get State:/Network/Service/97E8D482-1E2D-4743-B18D-FCA53A7151A7/DNS<br class="">
> d.show<br class="">
<dictionary> {<br class="">
ServerAddresses : <array> {<br class="">
0 : 10.8.65.164<br class="">
1 : 10.8.65.164<br class="">
}<br class="">
}<br class="">
> quit<br class="">
<br class="">
<br class="">
The DNS server is now reachable:</font>
<div class=""><font face="Monaco" class=""><br class="">
$ ping 10.8.65.164<br class="">
PING 10.8.65.164 (10.8.65.164): 56 data bytes<br class="">
64 bytes from 10.8.65.164: icmp_seq=0 ttl=63 time=100.418 ms<br class="">
64 bytes from 10.8.65.164: icmp_seq=1 ttl=63 time=114.527 ms<br class="">
64 bytes from 10.8.65.164: icmp_seq=2 ttl=63 time=100.445 ms<br class="">
^C<br class="">
--- 10.8.65.164 ping statistics ---<br class="">
3 packets transmitted, 3 packets received, 0.0% packet loss<br class="">
round-trip min/avg/max/stddev = 100.418/105.130/114.527/6.645 ms<br class="">
<br class="">
</font></div>
<div class=""><font face="Monaco" class=""><br class="">
</font></div>
<div class=""><font face="Monaco" class="">But no internal DNS name resolution as it’s using 8.8.8.8:</font></div>
<div class=""><font face="Monaco" class=""><br class="">
</font></div>
<div class=""><font face="Monaco" class="">$ ping ipa.cazena.internal<br class="">
ping: cannot resolve ipa.cazena.internal: Unknown host<br class="">
$ host ipa.cazena.internal<br class="">
Host ipa.cazena.internal not found: 3(NXDOMAIN)<br class="">
$ host -v ipa.cazena.internal<br class="">
Trying "ipa.cazena.internal"<br class="">
Received 112 bytes from 8.8.8.8#53 in 40 ms<br class="">
Trying "ipa.cazena.internal"<br class="">
Host ipa.cazena.internal not found: 3(NXDOMAIN)<br class="">
Received 112 bytes from 8.8.8.8#53 in 44 ms<br class="">
$ dig ipa.cazena.internal<br class="">
<br class="">
; <<>> DiG 9.8.3-P1 <<>> ipa.cazena.internal<br class="">
;; global options: +cmd<br class="">
;; Got answer:<br class="">
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14628<br class="">
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0<br class="">
<br class="">
;; QUESTION SECTION:<br class="">
;ipa.cazena.internal.<span class="Apple-tab-span" style="white-space:pre"> </span>
IN<span class="Apple-tab-span" style="white-space:pre"> </span>A<br class="">
<br class="">
;; AUTHORITY SECTION:<br class="">
.<span class="Apple-tab-span" style="white-space:pre"> </span>1756<span class="Apple-tab-span" style="white-space:pre">
</span>IN<span class="Apple-tab-span" style="white-space:pre"> </span>SOA<span class="Apple-tab-span" style="white-space:pre">
</span><a href="http://a.root-servers.net" class="">a.root-servers.net</a>. <a href="http://nstld.verisign-grs.com" class="">
nstld.verisign-grs.com</a>. 2015032300 1800 900 604800 86400<br class="">
<br class="">
;; Query time: 29 msec<br class="">
;; SERVER: 8.8.8.8#53(8.8.8.8)<br class="">
;; WHEN: Mon Mar 23 10:50:08 2015<br class="">
;; MSG SIZE rcvd: 112<br class="">
<br class="">
<br class="">
</font><br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On Mar 19, 2015, at 2:27 PM, Ken Nelson <<a href="mailto:ken@cazena.com" class="">ken@cazena.com</a>> wrote:<br class="">
<br class="">
Thanks to martin & Fred for your responses. I’m still having tunnel DNS server configuration trouble on the Mac client.<br class="">
<br class="">
Configuration is strongSwan OS X app version 5.2.2 (1) on OS X Yosemite v10.10.2 connecting to a StrongSwan version 5.2.2 gateway on Centos 6.6.<br class="">
<br class="">
Here is the scutil output. It looks like this both before and after the StrongSwan Mac app creates the tunnel.<br class="">
<br class="">
$ sudo scutil --dns<br class="">
DNS configuration<br class="">
<br class="">
resolver #1<br class="">
nameserver[0] : 72.250.183.10<br class="">
nameserver[1] : 72.250.183.20<br class="">
nameserver[2] : 10.100.36.2<br class="">
nameserver[3] : 8.8.8.8<br class="">
nameserver[4] : 8.8.4.4<br class="">
flags : Request A records<br class="">
reach : Reachable<br class="">
<br class="">
DNS configuration (for scoped queries)<br class="">
<br class="">
resolver #1<br class="">
nameserver[0] : 72.250.183.10<br class="">
nameserver[1] : 72.250.183.20<br class="">
nameserver[2] : 10.100.36.2<br class="">
nameserver[3] : 8.8.8.8<br class="">
nameserver[4] : 8.8.4.4<br class="">
if_index : 4 (en3)<br class="">
flags : Scoped, Request A records<br class="">
reach : Reachable<br class="">
<br class="">
<br class="">
Here’s a part of the StrongSwan Mac app log, showing the installation of the DNS server. The displayed address is the configured one on the VPN gateway.<br class="">
<br class="">
scheduling rekeying in 35565s<br class="">
maximum IKE_SA lifetime 36165s<br class="">
handling UNITY_SPLIT_INCLUDE attribute failed<br class="">
handling UNITY_LOCAL_LAN attribute failed<br class="">
installing 10.8.65.164 as DNS server<br class="">
handling UNITY_DEF_DOMAIN attribute failed<br class="">
installing 10.8.65.164 as DNS server<br class="">
installing new virtual IP 10.255.252.1<br class="">
created TUN device: utun1<br class="">
<br class="">
<br class="">
I don’t know that much about OS X DNS, other than it is not the /etc/resolv.conf flat file.<br class="">
<br class="">
What can I do to get more visibility into root cause?<br class="">
<br class="">
<br class="">
<br class="">
<blockquote type="cite" class="">On Mar 16, 2015, at 3:18 AM, Fred <<a href="mailto:curious_freddy@gmsl.co.uk" class="">curious_freddy@gmsl.co.uk</a>> wrote:<br class="">
<br class="">
On 16/03/2015 08:23, Martin Willi wrote:<br class="">
<blockquote type="cite" class="">Ken,<br class="">
<br class="">
<blockquote type="cite" class="">Are there any issues with DNS & StrongSwan Mac OS X app?<br class="">
</blockquote>
<br class="">
The osx-attr plugin prepends the negotiated DNS servers to the currently<br class="">
configured ones. You may check with scutil if that works as expected.<br class="">
<br class="">
Not sure if keeping the current DNS servers installed is the best<br class="">
approach, maybe we should remove the previous servers. But we currently<br class="">
just add them to have them as a fallback.<br class="">
</blockquote>
<br class="">
In my case the local DNS server was being used instead of the DNS servers added by strongSwan. I could clearly see the them added in the both the strongSwan logfile and also in the output of scutil --dns.<br class="">
<br class="">
If I deleted them all and then added just the ones via the VPN, it all worked fine.<br class="">
<br class="">
Personally I think removing the previous servers would be better. This problem did go away in Yosemite so maybe it was a bug in previous versions of Mac OS X or odd expected behaviour.<br class="">
_______________________________________________<br class="">
Users mailing list<br class="">
Users@lists.strongswan.org<br class="">
https://lists.strongswan.org/mailman/listinfo/users<br class="">
</blockquote>
<br class="">
</blockquote>
<br class="">
</div>
</div>
</body>
</html>