[strongSwan] StrongSwan Mac OS X app & DNS
Tim Soderstrom
strongswan at moocowproductions.org
Mon Mar 23 18:26:14 CET 2015
I had a lot of trouble with this too and the way I solved it was by using /etc/resolver. It has to do with OS X using two different DNS systems for some crazy reason (among the other number of quirks found in OS X for setting up a VPN).
To fix this, create a file under /etc/resolver (and optionally create that directory) with the same name as your VPN domain (e.g. example.vpn). Then put in the domain and name-server to handle lookups, e.g.:
# cat /etc/resolver/example.vpn
domain example.vpn
nameserver 172.24.0.1
In order to make that an easy install, you could try using an Automator script or something. I just have the steps well documented with a cut/paste kinda thing. So far, even non tech-savvy folks were able to get it going without much fuss.
I really REALLY wish Apple would spend more time focusing on important OS X issues over reskins but, sadly, that's not the world we currently live in.
Hope that helps!
Tim
> On Mar 23, 2015, at 12:11 PM, Ken Nelson <ken at cazena.com> wrote:
>
> 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. 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> 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> 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
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
More information about the Users
mailing list