Environment
Novell Access Manager 3.1.3-247 SSLVPN Server
MAC OS X Leopard
DNS servers configuration obtained through DHCP
MAC OS X Leopard
DNS servers configuration obtained through DHCP
Situation
Purpose:
Configure the SSLVPN server in order to push the internal DNS servers to the connecting workstations.
Symptoms:
MAC OS X users are not able to resolve internal DNS names when connected to the SSLVPN server.
Configure the SSLVPN server in order to push the internal DNS servers to the connecting workstations.
Symptoms:
MAC OS X users are not able to resolve internal DNS names when connected to the SSLVPN server.
Resolution
This is fixed in Novell Access Manager 3.1 Service Pack 3 IR
1
Additional Information
As described by Novell Access Manager 3.1 SP3 documentation,
whenever a MAC client connects to SSLVPN server in enterprise mode,
the DNS servers are pushed down and added as secondary
resolvers:
3.5 Configuring DNS Servers
The DNS servers configured in the SSL VPN server are pushed to the client during the connection. When a Linux or Windows client connects to the SSL VPN server, the existing DNS entry on the client is pushed as the secondary entry and the DNS entry configured on the SSL VPN server is pushed as the primary DNS entry. However, on a Mac client, the DNS entry configured on the SSL VPN server acts as the secondary DNS. After the SSL VPN connection, name resolution is done through the DNS entry configured before the SSL VPN connection. However, when the primary DNS server is not available, the DNS entry configured by the SSL VPN server takes care of DNS resolution for the client.
Even tough this is the default behaviour, was noticed that it can represent an issue for those environments where a split DNS configuration is in use and internal network names are known and resolved only from internal DNS servers.
As a matter of fact, was observed that MAC OS X Leopard would query the secondary resolver only if the primary is not reachable (timeout) or returns an error, while not when a "No Such Name" reply is received from the primary DNS server configured.
On Linux and Windows, were internal DNS names are pushed at the top of the resolver list, this issue doesn't occur. Normally the internal DNS servers are configured to forward queries to public DNS when they are not able to resolve a name, but of course not the other way around.
In Novell Access Manager 3.1 SP 3 IR1 the logic used to push internal DNS servers when connecting to the SSLVPN using MAC OS X Leopard has been changed so to add them at the top of the resolver list.
On MAC OS X Snow Leopard a different behaviour was observed, the OS is able to properly rotate DNS servers in case the primary resolver replies with "No Such Name", so in this case the internal DNS servers will still be added as secondary resolver.
3.5 Configuring DNS Servers
The DNS servers configured in the SSL VPN server are pushed to the client during the connection. When a Linux or Windows client connects to the SSL VPN server, the existing DNS entry on the client is pushed as the secondary entry and the DNS entry configured on the SSL VPN server is pushed as the primary DNS entry. However, on a Mac client, the DNS entry configured on the SSL VPN server acts as the secondary DNS. After the SSL VPN connection, name resolution is done through the DNS entry configured before the SSL VPN connection. However, when the primary DNS server is not available, the DNS entry configured by the SSL VPN server takes care of DNS resolution for the client.
Even tough this is the default behaviour, was noticed that it can represent an issue for those environments where a split DNS configuration is in use and internal network names are known and resolved only from internal DNS servers.
As a matter of fact, was observed that MAC OS X Leopard would query the secondary resolver only if the primary is not reachable (timeout) or returns an error, while not when a "No Such Name" reply is received from the primary DNS server configured.
On Linux and Windows, were internal DNS names are pushed at the top of the resolver list, this issue doesn't occur. Normally the internal DNS servers are configured to forward queries to public DNS when they are not able to resolve a name, but of course not the other way around.
In Novell Access Manager 3.1 SP 3 IR1 the logic used to push internal DNS servers when connecting to the SSLVPN using MAC OS X Leopard has been changed so to add them at the top of the resolver list.
On MAC OS X Snow Leopard a different behaviour was observed, the OS is able to properly rotate DNS servers in case the primary resolver replies with "No Such Name", so in this case the internal DNS servers will still be added as secondary resolver.