Tiny Deathstars of Foulness

I’ve been underwhelmed (if that’s a word) by the list of common ports used on the Apple platform recently, so I started my own. It’s available at if you’re interested. It’s also under the Tools menu of the site. And yes, I’m aware that I can cat /etc/services; this includes some rudimentary notes.

August 17th, 2015

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

Tags: , , , , , , , , ,

sFlow is an industry standard that allows network equipment with the appropriate agents to send data to sFlow collectors, which then analyze network traffic. You can install sFlow on routers, switches, and even put agents on servers to monitor traffic. Brocade (along with most other switch manufacturers) supports sFlow.

Before you do anything log into the switch and check the current flow configuration:

show sFlow

To configure, log into the switch and use the the int command to access an interface. From within the interface, use the following command:

sflow forwarding

Then exit the interface using the very difficult to remember exit command:


Repeat the enablement of forwarding for any other necessary interfaces. Next, we’ll configure a few globals that would be true across all interfaces. The first is the destination address, done using the destination verb followed by the IP and then the port (I’m using the default 6343 port for sFlow):

sflow destination 6343

Set the sample rate:

sflow sample 512

Set the polling interval:

sflow polling-interval 30

Finally, enable sFlow:

sflow enable

January 2nd, 2015

Posted In: Mac OS X, Mac OS X Server, Mac Security, Network Infrastructure, Xsan

Tags: , , , , , , , , ,

OS X Server has long had a VPN service that can be run. The server is capable of running the two most commonly used VPN protocols: PPTP and L2TP. The L2TP protocol is always in use, but the server can run both concurrently. You should use L2TP when at all possible.

Sure, “All the great themes have been used up and turned into theme parks.” But security is a theme that it never hurts to keep in the forefront of your mind. If you were thinking of exposing the other services in Mountain Lion Server to the Internet without having users connect to a VPN service then you should think again, because the VPN service is simple to setup and even simpler to manage.

Setting Up The VPN Service In Mountain Lion

To setup the VPN service, open the Server app and click on VPN in the Server app sidebar. The VPN Settings  screen has two options available in the “Configure VPN for” field, which has two options:

  • L2TP: Enables only the L2TP protocol
  • L2TP and PPTP: Enables both the L2TP protocol and the PPTP protocol

The VPN Host Name field is used by administrators leveraging profiles. The setting used becomes the address for the VPN service in the Everyone profile. L2TP requires a shared secret or an SSL certificate. In this example, we’ll configure a shared secret by providing a password in the Shared Secret field. Additionally, there are three fields, each with an Edit button that allows for configuration:

  • Client Addresses: The dynamic pool of addresses provided when clients connect to the VPN 
  • DNS Settings: The name servers used once a VPN client has connected to the server. As well as the Search Domains configuration.
  • Routes: Select which interface (VPN or default interface of the client system) that a client connects to each IP address and subnet mask over.
  • Save Configuration Profile: Use this button to export configuration profiles to a file, which can then be distributed to client systems (OS X using the profiles command, iOS using Apple Configurator or both using Profile Manager).

Once configured, open incoming ports on the router/firewall. PPTP runs over port 1723. L2TP is a bit more complicated (with keys bigger than a baby’s arm), running over 1701, but also the IP-ESP protocol (IP Protocol 50). Both are configured automatically when using Apple AirPorts as gateway devices. Officially, the ports to forward are listed at

Using The Command Line

I know, I’ve described ways to manage these services from the command line before. But, “tonight we have number twelve of one hundred things to do with your body when you’re all alone.” The serveradmin command can be used to manage the service as well as the Server app. The serveradmin command can start the service, using the default settings, with no further configuration being required:

sudo serveradmin start vpn

And to stop the service:

sudo serveradmin stop vpn

And to list the available options:

sudo serveradmin settings vpn

To disable L2TP, set to no:

sudo serveradmin settings = no

To configure how long a client can be idle prior to being disconnected:

sudo serveradmin settings = 10

By default, each protocol has a maximum of 128 sessions, configureable using

sudo serveradmin settings = 200

To see the state of the service, the pid, the time the service was configured, the path to the log files, the number of clients and other information, use the fullstatus option:

sudo serveradmin fullstatus vpn

Which returns output similar to the following:

vpn:servicePortsAreRestricted = "NO"
vpn:readWriteSettingsVersion = 1 = "MSCHAP2" = 0 = yes = "MPPEKeySize128" = "2012-07-31 02:05:38 +0000" = "PPP" = "PPTP" = "DSAuth" = 97849 = "MSCHAP2" = 0 = yes = "2012-07-31 02:05:39 +0000" = "PPP" = "L2TP" = "DSAuth" = 97852
vpn:servicePortsRestrictionInfo = _empty_array
vpn:health = _empty_dictionary
vpn:logPaths:vpnLog = "/var/log/ppp/vpnd.log"
vpn:configured = yes
vpn:state = "RUNNING"
vpn:setStateVersion = 1

Security folk will be stoked to see that the shared secret is shown in the clear using: = "a dirty thought in a nice clean mind"

Configuring Users For VPN Access

Each account that accesses the VPN server needs a valid account to do so. To configure existing users to use the service, click on Users in the Server app sidebar.

At the list of users, click on a user and then click on the cog wheel icon, selecting Edit Access to Services.

At the Service Access screen will be a list of services that could be hosted on the server; verify the checkbox for VPN is highlighted for the user.

Setting Up Client Computers

As you can see, configuring the VPN service in Mountain Lion Server is a simple and straight-forward process – much easier than eating your cereal with a fork and doing your homework in the dark.. Configuring clients is as simple as importing the profile generated by the service. However, you can also configure clients manually. To do so in OS X, open the Network System Preference pane. From here, click on the plus sign (“+”) to add a new network service.

At the prompt, select VPN in the Interface field and then either PPTP or L2TP over IPSec in the VPN Type. Then provide a name for the connection in the Service Name field and click on Create.

At the list of network interfaces in the Network System Preference pane, provide the hostname or address of the server in the Server Address field and the username that will be connecting to the VPN service in the Account Name field. If using L2TP, click on Authentication Settings.

At the prompt, provide the password entered into the Shared Secret field earlier in this article in the Machine Authentication Shared Secret field and the user’s password in the User Authentication Password field. When you’re done, click OK and then provided you’re outside the network and routeable to the server, click on Connect to test the connection.


Setting Up the VPN service in OS X Mountain Lion Server is as simple as clicking the ON button. But much more information about using a VPN can be required. The natd binary is still built into Mountain Lion at /usr/sbin/natd and can be managed in a number of ways. But it’s likely that the days of using an OS X Server as a gateway device are over, if they ever started. Sure “feeling screwed up at a screwed up time in a screwed up place does not necessarily make you screwed up” but using an OS X Server for NAT when it isn’t even supported any more probably does. So rather than try to use the server as both, use a 3rd party firewall like most everyone else and then use the server as a VPN appliance. Hopefully it can do much more than just that to help justify the cost. And if you’re using an Apple AirPort as a router (hopefully in a very small environment) then the whole process of setting this thing up should be super-simple.

July 31st, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, Network Infrastructure

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

DHCP provides IP addresses to clients. DHCP is critical to a number of Mac OS X Server technologies, most notably with NetBoot. In doing so, communications are comprised of 4 steps: Discovery, Offer, Acceptance, and Acknowledgment. In the Discovery step, a computer that needs an IP address sends a broadcast request to the environment. These typically remain local, although most routers will allow for configuring the gateway in such a way that UDP traffic is forwarded on to other subnets. The request also includes all of the options that the client will need, with options being anything beyond an IP address, each potential option with a numerical identifier per this list (defined in various RFPs).

In the second step, any DHCP servers that received the request will issue an offer, which includes a number of DHCP options, such as a subnet mask (option 1), a gateway (option 3), DNS servers (option 6), amount of time a lease is valid for (option 51), the IP of the DHCP server making the offer (option 54). For example, WINS is two options, 44 & 46 (server and type respectively) that can be provided to clients as is LDAP (option 95). Available options are determined based on any reservations that may have been filed. For example, if an IP address has been reserved for a specific MAC address then the IP will always be the IP reserved.

Because environments can have multiple DHCP servers the Transaction ID will determine which offer to accept. The servers that issued an offer will hold the IP address from the offer until they receive the response that another offer is being accepted and then move those back into their pool of available IP addresses. In step 3, Acceptance, the DHCP client will notify the server whose lease it accepts in the form of a DHCP Request, and those whose lease it will pass on. The Acceptance is actually a request for the IP address that is being held for the MAC address in question.

Based on the Acceptance, the options are then applied in an acknowledgement sent back to the client from the server that it indeed has the IP address and all of the pertinent options required. All of this typically happens in under a second and therefore, you plug in your computer and it gets an IP address; unless you’re running wireshark to look at what’s happening beneath the scene you typically just assume that that’s all there is to it… The most powerful part of DHCP though is in the options, which shows that great thought was given to the protocol when it was conceived. These extensions provide for anything from NTP servers to SMTP servers provided that the client and the server support the implementation.

October 6th, 2009

Posted In: Mac OS X, Mac OS X Server, Mass Deployment, Unix, Windows XP

Tags: , , , , , , ,