Set Up SSL VPN Remote Access on a SonicWall (NetExtender)

Before you run this

This guide configures SSL VPN (NetExtender) remote access on a SonicWall firewall: it opens an encrypted tunnel on the WAN so authorised users can dial in from the internet and reach an internal subnet. Everything here is done in the SonicOS web GUI as a full administrator account — there is no "script" to paste, but the changes are just as production-critical as one.

You will be changing the firewall that carries all your production traffic. Enabling SSL VPN on the WAN zone auto-creates access rules and opens a listening port to the internet. Get the address pool or the auto-created rules wrong and you can break routing or expose more than you intend. So:

Keep a second way in. Have a console/serial cable or an out-of-band management path ready. If you are working over the WAN GUI and you change the SSL VPN port to 443 or fumble a WAN rule, you can lock yourself out.
Back up the running config first. Go to DEVICE | Settings | Firmware and Settings and export the configuration (the .exp file) before you touch anything. That file is your rollback.
Do this in a maintenance window, and test with one throwaway test user before you add real staff.
Rollback path: re-import the .exp you just exported (same page, Import Configuration), or boot the previous settings image from the firmware/backups list. SonicOS does not have a timed auto-rollback like PAN-OS, so your exported config is the safety net — make it before, not after.

I am writing this for SonicOS 7.0/7.1 on a TZ or NSa appliance, single WAN, single internal LAN. If you are on SonicOS 6.5 the concepts are identical but the menus live in the old left-hand tree, so the exact clicks below will not match. Where I am not 100% certain of a field label I say so and point you at the SonicWall SonicOS 7 Administration Guide rather than guess.

Plan the addressing first

Decide on a client address pool that does not overlap any existing subnet — LAN, DMZ, other VPN pools, or the remote user's home LAN. NetExtender hands connecting clients an IP from this pool. A small dedicated range is normal, e.g. 192.168.200.1 – 192.168.200.50 if your LAN is 192.168.1.0/24.

Create it as an address object:

OBJECT | Match Objects | Addresses, then Add.
Name it something obvious like SSLVPN-Pool, Zone Assignment SSLVPN, Type Range, and enter the start/end IPs.

Also confirm you have an address object (or group) for the internal network you want users to reach, e.g. the auto-created LAN Subnets. You will reference it in two places later.

Enable the SSL VPN server

Go to NETWORK | SSL VPN | Server Settings.

Set the SSL VPN Port. The SonicWall default is 4433. Keep it unless you have a reason to change it. Do not set it to 443 if you also manage the box over HTTPS on the WAN — you will collide with the management service.
In the zone list on this page, enable SSL VPN access on the WAN zone (toggle/checkbox next to WAN). This is what makes the firewall listen for NetExtender on the WAN.
Optionally set the certificate. The default self-signed cert works, but users get a trust warning; a proper CA-signed cert bound here removes it. Certificate import lives under DEVICE | Settings | Certificates — see the admin guide for the exact import steps if you go that route.

When you enable SSL VPN on the WAN zone, SonicOS auto-creates the access rules from WAN to the SSLVPN zone. Don't delete those.

Configure client settings (the address pool and DNS)

Go to NETWORK | SSL VPN | Client Settings and edit the Default Device Profile (that is the profile NetExtender clients inherit).

Zone IP V4 / Network Address: point it at the SSLVPN-Pool address object you created.
DNS Server: set your internal DNS so clients can resolve internal hostnames.
User Domain / DNS Domain: your AD DNS suffix, e.g. example.com, if you want name resolution to work cleanly.

The exact field names on the Default Device Profile have shifted slightly between 7.0 and 7.1 point releases; if a label doesn't match, check the "SSL VPN | Client Settings" section of the SonicOS 7 Administration Guide rather than forcing a value into the wrong box.

Set client routes (what the tunnel carries)

Go to NETWORK | SSL VPN | Client Routes.

Add the internal network(s) you want reachable through the tunnel, e.g. LAN Subnets.
There is a Tunnel All Mode option that forces all client traffic through the firewall. Leave it off for split tunnel (only the routes you list go over the VPN) unless you specifically want to backhaul internet traffic too. Split tunnel is the mainstream choice for remote-access.

A client only gets to a subnet if it is listed here and allowed in the user's VPN Access (next step). Both are required.

Create a user and grant VPN access

Local users are the simplest path; LDAP/RADIUS against Active Directory is the other common option (configured under DEVICE | Users | Settings), but I'll do a local test user here.

DEVICE | Users | Local Users & Groups | Local Users, then Add.
Set the name (vpntest) and a strong password.
On the Groups tab, make the user a member of the built-in SSLVPN Services group. Membership in SSLVPN Services is what actually permits SSL VPN login — without it the user authenticates but is denied the tunnel.
On the VPN Access tab, add the network object the user is allowed to reach (e.g. LAN Subnets). This list is enforced independently of Client Routes.

Rather than editing every user, you can add the networks once on the VPN Access tab of the SSLVPN Services group and let members inherit them — cleaner for more than a couple of users.

Test with the NetExtender client

Download NetExtender from SonicWall (client.sonicwall.com / MySonicWall — get it from SonicWall directly, not a mirror). On a test machine that is not on your LAN (tether to a phone hotspot so you're genuinely coming in from the WAN):

Server: your.wan.ip:4433 (or your hostname and chosen port)
Username / Password: vpntest
Domain: LocalDomain for a local user, or your AD domain if using LDAP/RADIUS.

Verify it worked

On the firewall: MONITOR | current sessions / SSL VPN shows active sessions. In SonicOS 7 the live SSL VPN sessions are under MONITOR (Users / SSL VPN status) — the exact node name varies by build; look for the SSL VPN session list.
On the client: after connecting, NetExtender shows a client IP from your SSLVPN-Pool range. From that machine, ping an internal host and RDP/SSH to something you expect to reach.
Check DNS: nslookup internal-host.example.com should resolve via your internal DNS.

If NetExtender connects but nothing is reachable, the fault is almost always Client Routes or the user's VPN Access list — one of them is missing the target subnet.

Undo / roll back

Remove one test user: delete vpntest under Local Users, or just remove it from SSLVPN Services.
Disable the service entirely: in NETWORK | SSL VPN | Server Settings, turn off SSL VPN access on the WAN zone. This stops the listener; the auto-created WAN→SSLVPN access rules become inactive.
Full revert: import the .exp you exported in "Before you run this" via DEVICE | Settings | Firmware and Settings, or boot the previous settings image. The unit reboots and comes back exactly as it was.

Once the test user works end to end, repeat the user/group step for real staff — and if you have more than a handful, move authentication to LDAP/RADIUS and manage access through the SSLVPN Services group rather than per user.