Currently Being ModeratedJun 28, 2013 4:45 PM (in response to Melissa Hines)
Ensure DNS services are working and stable. On the server, launch Terminal.app from Applications > Utilities and issue the diagnostic command:
sudo changeip -checkhostname
Ensure that the VPN clients get the address of your on-LAN DNS server, and that all traffic is routed over the VPN.
I'd get out of the 192.168.1.0/24 subnet. VPNs will not work when both ends of the VPN connection are in the same subnet, as the underlying IP routing gets tangled. The 192.168.0.0/24 and 192.168.1.0/24 subnets are the two most common choices on the planet, and there are much better private subnets available; subnets much less likely to conflict with VPN use.
You'll need to probe the network and the vLANs for the issues connecting TCP port 5900; that's usually either a vLAN issue, a firewall issue, or the target server may have been reconfigured to disable screen sharing. (Trust what your network folks tell you about the configuration, but always verify it.)
There are a gazillion Linksys gateway-firewall-router boxes, of varying capabilities. The configuration of this gateway device will definitely need to be investigated. (I usually prefer to look to a slightly higher-end router than these, as many of the Linksys devices tend to target low-end and residential networks.)
Somebody in senior management likely needs to assist you in achieving your goals here, and to assist your IT staff in better understanding and meeting the goals of the organization.
Currently Being ModeratedJul 2, 2013 2:18 AM (in response to Melissa Hines)
I am struggling with one of the same issues. I am unable to access my Open Directory server via my domain name or IP address via internet. The dot next to the network account server is red when I'm trying to connect via the internet. I get the error 2100 as well. VPN is fine, all ports on the router are open, and if I could VPN into the Server at the login window, network authentication would work, I'm sure. But you can't and it doesn't. A quandary. So any ideas would be much appreciated.
Currently Being ModeratedJul 2, 2013 8:50 AM (in response to Simon Turnill)
We'll need some more details....
Are you attempting to VPN directly into OS X Server, or are you using (as is my preference) a VPN server in your firewall-gateway device?
(Why? VPNs and NAT also work at cross-purposes. The VPN wants to "know" the end-points of the connection, where NAT wants to hide that detail.)
L2TP in particular generally gets tangled when more than one VPN is established through NAT. Subsequent L2TP connections will generally get all but one of the connections kicked off. PPTP is better here as it was built to try to deal with the NAT traversal, but PPTP is less secure than L2TP. (Put another way, if you're testing VPN connectivity, try PPTP first.)
Using a VPN server in the firewall-gateway box means the VPN processing for the connection can occur "before" the NAT processing.
Rather than tangling with both VPN and OD together (either of which can kick the connection to the curn/kerb), I'd get the VPN working with a local user first, and — once that's stable and working — move to getting the OD connection working.
Also (as mentioned up-thread) ensure DNS is working. If that's not working from the OD server all the way through to the remote client DNS requests, OD probably won't work reliably.
Currently Being ModeratedJul 2, 2013 9:31 AM (in response to MrHoffman)
Thank you for your reply, MrHoffman.
– The changeip -checkhostname command works fine and shows no issues.
– Screen sharing now also works from the WAN (and LAN) side, so this must have been a temporary network issue. I assume this means there are no problems with port 5900.
– VPN should not be needed from the subnet I am on currently.
I will change the subnet as suggested later tonight once all of the users are off; however, this does not appear to be . I found very useful background reading / instructions on this issue at http://labs.hoffmanlabs.com. I assume we have you to thank for this, so thank you!
Do you have any suggestions as to how I could probe or test the connection to the OD server besides trying "Join" the Network Account Server in Users & Groups?
Thank you for your help and advice,
Currently Being ModeratedJul 2, 2013 11:26 AM (in response to Melissa Hines)
I usually use either telnet (non-SSL/TLS ports) or openssl s_client (SSL/TLS ports) or maybe nc (for scanning ranges of TCP and UDP ports) to check access to specific ports from the command line, though it's very simple to run a port scan via Network Utility for this case. Launch that remotely, and see what your client can see.
Here is a list of the ports used by Apple (TS1629) For Open Directory, you'll need at least TCP 389 or preferably 636 punched through your gateway and your local firewall, if you're not VPN'ing in. If you're using your own DNS, you'll need TCP port 53 open (and this is mildly hazardous to your bandwidth, as more than a few folks are using DNS servers as part of DDoS attacks; they'll spoof queries and cause your DNS servers to send a reply at somebody else as part of the DDoS. The DNS servers really need to be locked down against this dreck.)
You may also need to aim your client's DNS explicitly at your own DNS server, if you're using a private domain and a private IP address space; if your servers don't have public IP addresses and public names.
Personally, I generally wouldn't expose the Open Directory ports to the 'net, or most anything else for that matter. I'd usually VPN into the network, and "DMZ" the web-facing stuff where I can. Too much weird cruft is hitting the firewalls I'm monitoring, undoubtedly looking for weaknesses and vulnerabilities. Using the VPN services isn't a panacea, but does mean your traffic is hidden from most monitoring, your servers' ports and services are relatively protected, your DNS services are your own, and your exposure is largely limited to the VPN server access.
For the remote clients, I'd use Portable Home Directory for the wandering devices, or straight OD via VPN.
Currently Being ModeratedJul 13, 2013 8:54 AM (in response to MrHoffman)
These hints helped very much. Thank you. In the end, there were two problems. First, the person who set up the router had enabled DNSMasq. As a result, Network Utility showed the expected open ports on the server when interrogated from the LAN, but no open ports from the WAN. Flipping this setting resolved that issue. Second, I set up the VPN on the server then connected on the client using Network in System Preferences. With these two changes, I can bind to the network account server (green light next to Network Account Server in Users & Groups).
I now have the same problem as Simon Turnill (above). I assume the solution to this problem is to use a portable home directory/mobile account. My first attempt at doing this did not work, but I assume this is straightforward.
This solution has created a second problem, though. From off campus I must first use Cisco VPN to tunnel to campus and then use the Mac VPN to tunnel to my server. From my cursory exploration, this appears to be impossible.
As a result, I need to disable the VPN on my server. Does anyone have any ideas as to why I can bind to the server with a VPN enabled on the server but not when the VPN is disabled? Any ideas appreciated.