The OS X Server would have 2 NICs with one on the WAN and the other on the LAN. The WAN would have the WAN IP and the LAN would run the LAN subnet. For this there would be no need for DNS or DHCP running on the remote box. The gateway setup assistant will config all of the conf files for you and then we would use the s2svpn command line utilities to configure an MD-5 CRAM hash to encrypt all data running over our custom tunnels. Then, we’d troubleshoot the connection. For more info on the specific command line utils,
It’s all CLI stuff. You can man s2svpnadmin for more info on the suite of options for the CLI. We would probably use shared secret rather than certificate based, unless I can get a CA to give me a cert which I’m currently working on getting for testing purposes. s2ssvpnadmin is an interactive CLI tool, so it goes through a q and a session with the admin and then sets its daemon (a combination of sshd and vpnd) to run per the steps we go through. Basically, we’ll feed it the two WAN IPs and a shared secret and then set some policies for how it communicates. This is something that is not documented anywhere on the net or in print at this point, so it’s fairly cutting edge as far as Open Source and OS X Server are concerned… The documentation of the CLI tools is also sparse.
The big thing is to get through the second phase and establish a connection and test the policies we build in the s2s. We’ll be exploring ppp and vpnd as far as ancillary CLI tools go. Probably be easy to give me TB2 or ARD or SSH access into the remote box and let me go to town. Once you see a bunch of XMen on your network we’re good (all my systems at home are named after XMen). One of my main goals is to discover the limitations behind using s2s in conjunction with AFP, FTP, SMB, mDNS, printing and finally the NetGear 318 router, which is compatible with the s2s options available to the Open Source community. NetGear is sending me an NFR through the Publisher.
Specific files we’ll be editing or running will be:
/usr/sbin/s2svpnadmin
/usr/share/servermgrd/bundles/servermgr_vpn.bundle/Contents/Resources/s2sAddSvr.plist
/usr/share/servermgrd/bundles/servermgr_vpn.bundle/Contents/Resources/s2sCertList.plist
/usr/share/servermgrd/bundles/servermgr_vpn.bundle/Contents/Resources/s2sDelSvr.plist
/usr/share/servermgrd/bundles/servermgr_vpn.bundle/Contents/Resources/s2sListSvrs.plist
/usr/share/servermgrd/bundles/servermgr_vpn.bundle/Contents/Resources/s2sSvrState.plist
The other unknown is what happens once the VPN is configured if one of the servers needs a reboot. Do we have to start over? Can we do something like what they do on a Cisco and save the conf into NVRAM? Since this is all CLI, no one has explored the implicit limitations.
