krypted.com

Tiny Deathstars of Foulness

Synology is able to do everything a macOS Server could do, and more. So if you need to move your VPN service, it’s worth looking at a number of different solutions. The most important question to ask is whether you actually need a VPN any more. If you have git, mail/groupware, or file services that require remote access then you might want to consider moving these into a hosted environment somewhere. But if you need access to the LAN and you’re a small business without other servers, a Synology can be a great place to host your VPN services. 

Before you setup anything new, first snapshot your old settings. Let’s grab  which protocols are enabled, running the following from Terminal:

sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:enabled

sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:enabled

Next, we’ll get the the IP ranges used so we can mimic those (or change them) in the new service:

sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:IPv4:DestAddressRanges

Now let’s grab the DNS servers handed out so those can be recreated:

sudo serveradmin settings vpn:Servers:com.apple.ppp.pptp:DNS:OfferedServerAddresses:_array_index
sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:DNS:OfferedServerAddresses:_array_index

Finally, if you’re using L2TP, let’s grab the shared secret:

sudo serveradmin settings vpn:Servers:com.apple.ppp.l2tp:L2TP:IPSecSharedSecretValue

Once we have all of this information, we can configure the new server using the same settings. To install the VPN service on a Synology, first open the Synology and click on Package Center. From there, click on All and search for VPN.

Then click on the Install button for VPN. Once installed, open VPN Server from the application launcher in the upper left-hand corner of the screen. Initially, you’ll see a list of the services that can be run, which include the familiar PPTP and L2TP, along with the addition of Open VPN.

Before we potentially open up dangerous services to users we might not want to have access to, click on Privilege. Here, enable each service for each user that you want to have access to the VPN services.

Now that we can safely enable and disable each of the services, click on PPTP in the sidebar of the VPN Server app (if you want to provide PPTP-based services to clients).

Here, check the box for “Enable PPTP VPN server” and enter the following information:
  • Dynamic IP address: The first DHCP address that will be given to client computers
  • Maximum connection number: How many addresses that can be handed out (and therefore the maximum number of clients that can connect via PPTP).
  • Maximum number of connections with the same account: How many sessions a given account can have (1 is usually a good number here).
  • Authentication: Best to leave this at MS-CHAP v2 for compatibility, unless you find otherwise.  
  • Encryption: Leave as MPPE optional unless all clients can do MPPE and then you can enforce it for a stronger level of encryption.
  • MTU: 1400 is a good number.
  • Use manual DNS: If clients will connect to services via names once connected to the VPN, I’d put your primary DNS server in this field.

Click Apply and open port 1723 so clients can connect to the service. If you’ll be using L2TP over IPSec, click on “L2TP/IPSec” in the sidebar. The settings are the same as those above, but you can also add a preshared key to the mix. Go ahead and check the enable checkbox, provide the necessary settings from the PPTP list, and provide that key and then click on Apply. Note that the DHCP pools are different between the two services. Point UDP ports 1701, 500, and 4500 at the new server to allow for remote connections and then test that clients can connect.

That’s it. You’ve managed to get a new VPN setup and configured. Provided you used the same IP address, same client secret, and the ports are the same, you’ll then be able to probably use the same profile to install clients that you were using previously.

April 6th, 2018

Posted In: Mac OS X Server, Mac Security, Synology

Tags: , , , , , , ,

One of the main reasons people get a server is to share files. Mac OS X Server is one of the more common devices used to share files to Mac OS X clients, using afp, the default file sharing protocol for Mac OS X. But you don’t have to use Mac OS X Server. You can use Linux as well. We’re going to look at using an open source project called netatalk to do so. If you find that after reading this that you’d like to find out more about netatalk then check out the open source project page at http://netatalk.sourceforge.net. The netatalk installer can be installed through most of the package installers for Linux. However, due to licensing issues with many versions of Linux, some of what you need might not come with the source, namely that Mac OS X 10.5 and above will not be able to authenticate to the netatalk daemon due to the lack of uams so files for dhx. Therefore, we’re going to look at building netatalk from source using apt-get in Ubuntu or Debian (for Redhat, use yum). To get started let’s get our dependencies (everything in this article needs to be run with elevated privileges):
apt-get install dpkg-dev devscripts libssl-dev fakeroot cracklib2-dev
Now let’s grab the netatalk source:
apt-get source netatalk
Now let’s get any other dependencies we might not have noticed already:
apt-get build-dep netatalk
Now cd into the netatalk directory (current version is 2.0.3):
cd netatalk-2.0.3
Now let’s tell it to build with SSL enabled:
DEB_BUILD_OPTIONS=ssl debuild
And to finally run the built package:
dpkg -i ../netatalk_*.deb
Next, let’s choose which authentication mechanisms we want to support. I practically always enable the pam modules so that netatalk can pass authentication back through my directory service and it’s very important that for Mac OS X 10.5 and above support that you make sure to go ahead and enable dhx as well. For most environments I’ll also disable cleartext passwords at this time. This is all done in the /etc/netatalk/afpd.conf file. At the bottom, by default you will see a list of authentication modules. Add the following line, adding any additional uams modules you’d like to support and removing any you would not like to support:
– -transall -uamlist uams_guest.so,uams_dhx_pam.so,uams_dhx_passwd.so,uams_dhx.so
We can also go ahead and restrict users from being able to save their password using the -nosavepassword option, meaning the line would instead appear as follows:
– -transall -uamlist uams_guest.so,uams_dhx_pam.so,uams_dhx_passwd.so,uams_dhx.so -nosavepassword
Note: The afpd.conf man page and the project documentation will lay out more about what each of these does. Once you have updated afpd.conf you will want to edit the /etc/netatalk/AppleVolumes.default file, which is where you create your shares. At the bottom of this file you’ll want to add a line that adds each new share (home directories are automatically shared by default). Here, you’ll specify the path to the share, followed by how you want the share to appear in the connect to server dialog, followed by an allow statement of who is able to access the share and then the options for the share (options are indicated in the man page and have commented descriptions in the actual file):
/SHARED/Accounting “Accounting” allow:accounting,root options:crlf,noadouble,mswindows,nodots,usehex dbpath:/tmp
The above file is also where you would make changes to the method used to store authentication database used (ie – using CNID In order to have different daemons or more likely to kill off the AppleTalk daemon) you’ll need to customize the /etc/default/netatalk file. Here, you can choose whether AppleTalk will run (ATALKD_RUN, whether to use bdb (CNID_METAD_RUN) and whether or not AFP will run (AFPD_RUN). You can also choose a maximum number of users to hit the server (AFPD_MAX_CLIENTS) and set AppleTalk names and zones if you’re running AppleTalk (ATALK_NAME and ATALK_ZONE respectively). And by default, AFP guests (AFPD_GUEST) are mapped to nobody (for permissions)… Once you’ve made your changes, save and then let’s restart the daemon and test connectivity:
/etc/init.d/netatalk restart
While testing, I usually like to run a tail of syslog to see if any errors pop up:
tail -f /var/log/syslog
When new versions come out, you will then be able to perform an update using apt-get as well:
apt-get update && apt-get install netatalk
If you find that through this you installed some things that you’d like to get rid of or that you’d like to start over, you can get rid of netatalk using the apt-get autoremove option:
apt-get autoremove netatalk
And if you don’t want the dependencies either, check out deborphan to clean those up as well!

November 12th, 2010

Posted In: Mac OS X Server, Ubuntu, Unix

Tags: , , , , , , , , , , , , , , , , , , ,

In a number of environments, where SMB, AFP and other file sharing protocols are used with Mac OS X, Windows and Linux clients, there are a number of hidden files that Mac OS X leaves behind. For anyone who has managed an environment like this you’re likely to notice the .DS_Store files and potentially even have tried taking measures to get rid of them. However, try as you might they’re likely to have come back repeatedly. But you don’t have to live with them. You can tell your Windows clients not to show hidden files.  From Windows XP, open an explorer.exe window (Windows Explorer, also accessible by browsing any folder on the hard drive) and from here click on the View tab and then click on Do not show hidden files and folders.  For Vista and up, click on the Folder Options control panel and then choose the View tab and then click on Do not show hidden files and folders. But if this is proving unwieldy then you can tell each Mac OS X user account not to make them.  This isn’t to say that you should – this is how Mac OS X tracks the view and icon placements of a folder.  But if you need to get rid of them you need to get rid of them…  To do so you’re going to create a file called com.apple.desktopservices.plist in the ~/Library/Preferences of each user account that contains the following:
{ DSDontWriteNetworkStores = true; }
The easiest way to go about this is to simply run the following command for each user on each system:
defaults write com.apple.desktopservices DSDontWriteNetworkStores true
You can use the com.apple.desktopservices.plist as a managed preference, or for future users you can also go ahead and add the file to the user template by dropping it into /System/Library/User Template/English.lproj/Library/Preferences. While this will keep new .DS_Store files from being generated on network volumes (aka NetworkStores) it will not do so for local volumes, including those on an Xsan (since Xsan volumes are basically interpreted by the finder as a local volume in this context).  It’s also worth noting that you’ll probably need to reboot after you run these commands. Once you’ve disabled the creation of new .DS_Store files you’ll more than likely want to eliminate the ones that are already on your volume.  To do so, you can use the find command in conjunction with the -name flag and -exec flag followed by rm as follows (replacing /path/to/share with the path to your actual share):
find /path/to/share -name .DS_Store -exec rm {} ;
For the above command to process correctly you’ll need the account it’s run as to be able to access files in all folders of the tree where a .DS_Store file may exist.  If you find that new .DS_Store files are created after this is all complete, then look at the owner of the new files.  Typically you’ll find a user account was skipped and it’s the user who is listed as the owner of the new .DS_Store files.

May 24th, 2009

Posted In: Mac OS X, Mac OS X Server, Mass Deployment, Ubuntu, Unix, Xsan

Tags: , , , , , , , , ,