SonicWALL Authentication on OS X

This guide covers how to setup a SonicWALL with consistent rules, and integrate its VPN authentication into Open Directory.

Basic Stuff

First off, if you’ve purchased it, upgrade the device to the Enhanced firmware. Standard firmware will not give you features like failover and true address objects. Note that SonicOS 3.x is pretty broken when it comes to LDAP; as in, it doesn’t work. SonicOS 4.x works fine.


Address Objects and Groups

As recommended by an engineer at SonicWALL, you should standardize your Address Object format so that you don’t go insane when looking at dozens of firewall rules.

Address Object format: (Type)-(Zone)-(Hostname or Description)-(IP)

Types:
H = Host
N = Network
S = Service
G = Group

Examples:
H-WAN-Mail-65.12.23.34 – a host on the WAN zone (publicly accessible) named Mail with the IP 65.12.23.34.
N-VPN-MyNetwork-192.168.1.0 – a network on the VPN zone named MyNetwork, with the subnet 192.168.1.0.

Also recommended was to create a Group object whenever there is more than one rule. This keeps things manageable.

Setting up LDAP Authentication with Open Directory

In this section we will setup the SonicWALL to authenticate against Open Directory. This guide was created under SonicOS Enhanced 4.0 on a PRO 2040, with OS X Server 10.5.4. OD integration gives us two benefits:

  • a “VPN Users” group can be maintained on the Mac. No need to login to the SonicWALL to edit VPN user accounts. All the benefits that come with OD- the same password everywhere, for example- come with this.
  • users that are members of the Directory Administrators group will be given admin access to the SonicWALL. (Probably – need to test.)

Setup the SonicWALL for Open Directory

  • Go to Users > Settings.
  • Change the authentication method to “LDAP + Local Users” and click the Configure button.
  • Use the following settings:
    • Settings tab
    • Name or IP address: (your LDAP server’s IP)
    • Port Number: (leave alone)
    • Server Timeout: 10 seconds
    • Anonymous login: checked
    • Protocol version: LDAP version 3
    • Use TLS (SSL): checked
    • Send LDAP ‘Start TLS’ request: unchecked
    • Require valid certificate from server: unchecked
    • Local certificate for TLS: None (I tried importing a self-signed CA cert but it doesn’t show up, not sure why. Actually nothing shows up here.)
    • (Definitely you’ll want to import your self-signed cert. It’s in the main sidebar under Certificates.)
    • Schema tab
    • LDAP Schema: User defined
    • User object class: posixAccount
    • Login name attribute: uid
    • Qualified login name attribute: uid
    • User group membership attribute: (empty, only Active Directory uses this field)
    • Framed IP address attribute: (empty, it has something to do with assigning a pre-defined IP address to VPN users)
    • User group object class: posixGroup
    • Member attribute: memberUid
    • User ID radio button: checked
    • Directory tab
    • (NOTE: I’m going to use examples here.)
    • Primary domain: dc=servername,dc=example,dc=com
      Example: dc=mars,dc=itwarriors,dc=com
    • User tree for login to server: (empty, not needed for anonymous login)
    • Trees containing users: cn=users,dc=servername,dc=domain,dc=com
      Example: cn=users,dc=mars,dc=itwarriors,dc=com
    • Trees containing user groups: cn=groups,dc=servername,dc=clientname,dc=com
      Example: cn=groups,dc=mars,dc=itwarriors,dc=com
    • ANOTHER NOTE: If you get an error about an LDAP schema mismatch, check the Primary Domain field. Either you should be using all DN-style syntax (e.g. cn=groups,dc=itwarriors,dc=com) or all AD-style syntax (e.g. itwarriors.com/Groups). Otherwise you’ll get this error if your fields are inconsistent.
    • LDAP Users tab
    • Allow only users listed locally: unchecked
    • User group memberships can be set locally by duplicating LDAP user names: unchecked
    • Default LDAP User Group: Everyone (but you can change depending on your security policy. I use Everyone because it’s nice and restricted.)
    • NOTE: At this point, assuming you’ve applied the previous settings, when you click the Import User Groups button, you should see your OD groups.
    • Import the desired groups. I made a group in Workgroup Manager called “VPN Users” (shortname: vpnusers) and imported it, along with OD Admins (shortname: admin) with this box. Just the two groups.
    • LDAP Relay tab
    • We ignore this tab.
    • Test tab
    • Enter the shortname of a user in OD, as well as their OD password. When you hit Test, you should receive a response.
    • If you’ve defined groups correctly you’ll get a “Member of:” line with the groups they’re a member of (if any). I don’t think domain users will count.
  • Add privileged groups (e.g. vpnusers, admin) from your OD to your SonicWALL if you haven’t already. See the LDAP Users tab instructions above.
  • Edit your Group VPN policy to allow users in group “vpnusers” access to the VPN.
    • Open your Group VPN policy (VPN > Settings > edit Group VPN policy)
    • Click the Advanced tab.
    • Require Authentication of VPN Clients via XAUTH: checked
    • User Group for XAUTH Users: vpnusers (this is the group I made in Workgroup Manager; obviously just choose the one that will contain only people you want to have VPN access.)
    • NOTE: What this basically does is only allow members of the group “vpnusers” to be seen by the SonicWALL’s XAUTH system. If someone isn’t a member of “vpnusers,” and they try to connect with the right PSK and their OD credentials, they’ll get a nice “XAUTH authentication failed” message, just as if you had deleted their local account on the SonicWALL.
  • Verify the SonicWALL groups are fine.
    • Go to Users > Local Users and expand All LDAP Users. You’ll see two users: “Everyone” and “Trusted Users.” Edit each one:
    • “Everyone” > VPN Access tab. There should be no entries under the Access List.
    • “Trusted Users” > VPN Access tab. The Access List should have Firewalled Subnets in it. (Or whatever you’d like to restrict them to.)
  • Test.

VPN Client for OS X

This is outside the scope of this article, but I have had very good luck with the freeware IPSecuritas client, from Lobotomo Software. It’s an IPSec VPN client that supports XAUTH, which the SonicWALL uses.

IPSecuritas Settings – just to get you started

Life will be much easier if you use the following settings in IPSecuritas’ Options tab when connecting to the SonicWALL:

  • Checked: IPSec DOI, SIT_IDENTITY_ONLY, Initial Contact, Local IP in Remote Network, Generate Policy, Request Certificate, Verify Certificate, Send Certificate, Unique SAs, IKE Fragmentation
  • Unchecked: Verify Identifier, Enable MODE_CFG, Disable collision check, Support Proxy, Passive, Enable Connection Check
  • NAT-T should be set to Disable.

6 thoughts on “SonicWALL Authentication on OS X

  1. Hi,
    Thanks for the guide!
    Any success in getting an iOS(4) device to connect to this?
    It seems to me, that it fails on Phase 2.. :-(

    I have the LDAP running and test is fine!

  2. Came across this guide when troubleshooting a clients new SonicWall NSA 240 that wouldn’t let me NAT UDP 500 to their OS X 10.5.8 Server.

    Found that SonicOS 5.1 Enhanced will actually allow the built in OS X VPN client to connect to the SonicWall VPN using Sonicwall local users!

    While this is good news, ideally one would like central user administration as well as using the OS’ built in VPN clients against the SonicWall.

    Using the guide I was able to setup the SonicWall to query the OS X server for users/groups, and test authentication using Password authentication, but it fails miserably for CHAP. The OS X Server OD supports MS-CHAPv2.

    Any clues much appreciated.

  3. I have done the SonicWall setup as specified I believe. I’m getting an error: Error Contacting LDAP Server. I called SonicWall for help earlier and they don’t seem to have anyone who has worked with Mac OS X. They could only find your notes on the internet to help me. I have tried to look at log files to find more details about the error message, but I’m not seeing anything that pops out at me. I would appreciate any help you can give me. At first SSL was not set up on my open directory master–I checked it–is there anything else I need on the OS X side that I might be missing that could cause this problem in contacting the server?

  4. @Martinus

    I set up a TZ 210 running Enhanced OS 5.8.1.5 today, and I was able to get it working with an Xserve running MOSXS 10.6.8 using the above instructions. A couple of quick notes:

    1. After saving the user-defined settings for the LDAP schema, the OS changed it to “RFC2307 Network Information Service”, which indicates that Sonicwall has added that functionality into the OS for us.

    2. Authentication via MOSX 10.6.8 (client and server) built-in VPN only works if the L2TP service is configured for PAP. CHAP, MS-CHAP, and MS-CHAPv2 all fail.

    Thanks for posting this page!

  5. Hi
    I had some trouble after the Lion to Mountain Lion update. Now, a few Mac Updates later LDAP seems to work again. So, this will still work with the latest 5.8 Sonicwall Firmware and Mountain Lion. Thanks for the guide, it was very Helpful!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>