[strongSwan] StrongSwan Mac OS X app & DNS
Ken Nelson
ken at cazena.com
Mon Mar 23 18:11:12 CET 2015
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.
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?
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.
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.
Here’s the state of the Mac’s DNS configuration prior to connecting:
$ scutil --dns
DNS configuration
resolver #1
nameserver[0] : 8.8.8.8
nameserver[1] : 8.8.4.4
flags : Request A records
reach : Reachable
order : 5000
DNS configuration (for scoped queries)
resolver #1
nameserver[0] : 8.8.8.8
nameserver[1] : 8.8.4.4
if_index : 4 (en3)
flags : Scoped, Request A records
reach : Reachable
order : 5000
$ scutil
> get State:/Network/Global/IPv4
> d.show
<dictionary> {
PrimaryInterface : en3
PrimaryService : 97E8D482-1E2D-4743-B18D-FCA53A7151A7
Router : 10.0.1.1
}
> get State:/Network/Service/97E8D482-1E2D-4743-B18D-FCA53A7151A7/DNS
> d.show
<dictionary> {
ServerAddresses : <array> {
}
}
> quit
The DNS server to be added is not reachable (tunnel down):
$ ping 10.8.65.164
PING 10.8.65.164 (10.8.65.164): 56 data bytes
Request timeout for icmp_seq 0
^C
--- 10.8.65.164 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
When connecting to the VPN gateway, the Mac app log shows:
handling UNITY_SPLIT_INCLUDE attribute failed
handling UNITY_LOCAL_LAN attribute failed
installing 10.8.65.164 as DNS server
handling UNITY_DEF_DOMAIN attribute failed
installing 10.8.65.164 as DNS server
The insertion of the DNS server’s IP (twice) is confirmed by scutil:
$ scutil
> get State:/Network/Global/IPv4
> d.show
<dictionary> {
PrimaryInterface : en3
PrimaryService : 97E8D482-1E2D-4743-B18D-FCA53A7151A7
Router : 10.0.1.1
}
> get State:/Network/Service/97E8D482-1E2D-4743-B18D-FCA53A7151A7/DNS
> d.show
<dictionary> {
ServerAddresses : <array> {
0 : 10.8.65.164
1 : 10.8.65.164
}
}
> quit
The DNS server is now reachable:
$ ping 10.8.65.164
PING 10.8.65.164 (10.8.65.164): 56 data bytes
64 bytes from 10.8.65.164: icmp_seq=0 ttl=63 time=100.418 ms
64 bytes from 10.8.65.164: icmp_seq=1 ttl=63 time=114.527 ms
64 bytes from 10.8.65.164: icmp_seq=2 ttl=63 time=100.445 ms
^C
--- 10.8.65.164 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 100.418/105.130/114.527/6.645 ms
But no internal DNS name resolution as it’s using 8.8.8.8:
$ ping ipa.cazena.internal
ping: cannot resolve ipa.cazena.internal: Unknown host
$ host ipa.cazena.internal
Host ipa.cazena.internal not found: 3(NXDOMAIN)
$ host -v ipa.cazena.internal
Trying "ipa.cazena.internal"
Received 112 bytes from 8.8.8.8#53 in 40 ms
Trying "ipa.cazena.internal"
Host ipa.cazena.internal not found: 3(NXDOMAIN)
Received 112 bytes from 8.8.8.8#53 in 44 ms
$ dig ipa.cazena.internal
; <<>> DiG 9.8.3-P1 <<>> ipa.cazena.internal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14628
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ipa.cazena.internal. IN A
;; AUTHORITY SECTION:
. 1756 IN SOA a.root-servers.net<http://a.root-servers.net>. nstld.verisign-grs.com<http://nstld.verisign-grs.com>. 2015032300 1800 900 604800 86400
;; Query time: 29 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Mar 23 10:50:08 2015
;; MSG SIZE rcvd: 112
On Mar 19, 2015, at 2:27 PM, Ken Nelson <ken at cazena.com<mailto:ken at cazena.com>> wrote:
Thanks to martin & Fred for your responses. I’m still having tunnel DNS server configuration trouble on the Mac client.
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.
Here is the scutil output. It looks like this both before and after the StrongSwan Mac app creates the tunnel.
$ sudo scutil --dns
DNS configuration
resolver #1
nameserver[0] : 72.250.183.10
nameserver[1] : 72.250.183.20
nameserver[2] : 10.100.36.2
nameserver[3] : 8.8.8.8
nameserver[4] : 8.8.4.4
flags : Request A records
reach : Reachable
DNS configuration (for scoped queries)
resolver #1
nameserver[0] : 72.250.183.10
nameserver[1] : 72.250.183.20
nameserver[2] : 10.100.36.2
nameserver[3] : 8.8.8.8
nameserver[4] : 8.8.4.4
if_index : 4 (en3)
flags : Scoped, Request A records
reach : Reachable
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.
scheduling rekeying in 35565s
maximum IKE_SA lifetime 36165s
handling UNITY_SPLIT_INCLUDE attribute failed
handling UNITY_LOCAL_LAN attribute failed
installing 10.8.65.164 as DNS server
handling UNITY_DEF_DOMAIN attribute failed
installing 10.8.65.164 as DNS server
installing new virtual IP 10.255.252.1
created TUN device: utun1
I don’t know that much about OS X DNS, other than it is not the /etc/resolv.conf flat file.
What can I do to get more visibility into root cause?
On Mar 16, 2015, at 3:18 AM, Fred <curious_freddy at gmsl.co.uk<mailto:curious_freddy at gmsl.co.uk>> wrote:
On 16/03/2015 08:23, Martin Willi wrote:
Ken,
Are there any issues with DNS & StrongSwan Mac OS X app?
The osx-attr plugin prepends the negotiated DNS servers to the currently
configured ones. You may check with scutil if that works as expected.
Not sure if keeping the current DNS servers installed is the best
approach, maybe we should remove the previous servers. But we currently
just add them to have them as a fallback.
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.
If I deleted them all and then added just the ones via the VPN, it all worked fine.
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.
_______________________________________________
Users mailing list
Users at lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150323/7e20736c/attachment-0001.html>
More information about the Users
mailing list