NetCrosswalk: Cross-Vendor Network Task Translator

WireGuard (recommended, RouterOS 7.x)

1. Create the interface: /interface wireguard add name=wg0 listen-port=13231.
2. Give the router a tunnel address: /ip address add address=10.10.0.1/24 interface=wg0.
3. For each user, generate a key pair on their own device (or with /interface wireguard print after adding a placeholder peer, then have them generate their own and send you the public key — never generate a user's private key for them if you can avoid it).
4. Add the peer: /interface wireguard peers add interface=wg0 public-key="<their-public-key>" allowed-address=10.10.0.10/32.
5. Allow the port through the firewall: /ip firewall filter add chain=input protocol=udp dst-port=13231 action=accept place-before=0.
6. Give the user a config: server public key (/interface wireguard print), the router's WAN address:13231 as endpoint, their assigned 10.10.0.10/32 as the WireGuard interface address, and AllowedIPs set to whatever internal ranges they should reach.
7. Verify: /interface wireguard peers print — check last-handshake after the client connects.

• No licence, minimal config, works from any OS with the standard WireGuard client. There is no MikroTik-branded client — users install the official WireGuard app.
• WireGuard has no user database: each client is a peer with a key pair, so onboarding is manual and revocation means deleting the peer. There is no MFA without external tooling in front of it.
• allowed-address on the router side is a routing statement, not an ACL — overlapping values between peers break routing, and it also controls which source IPs the router accepts from that peer.

IKEv2 with certificates

1. Build a small CA: /certificate add name=ca-template common-name=vpn-ca key-usage=key-cert-sign → /certificate sign ca-template.
2. Issue a server certificate signed by that CA: /certificate add name=server-cert common-name=<router-wan-fqdn> → /certificate sign server-cert ca=ca-template.
3. Issue one client certificate per user the same way, then export it with the private key (/certificate export-certificate client1-cert export-passphrase=<temp-password>) and get the .p12 file to that user securely.
4. Create the address pool and mode-config: /ip pool add name=ikev2-pool ranges=10.20.0.10-10.20.0.100 then /ip ipsec mode-config add name=ikev2-modecfg address-pool=ikev2-pool address-prefix-length=32 system-dns=yes.
5. Create the profile, proposal, and peer: /ip ipsec profile add name=ikev2-profile dh-group=modp2048 enc-algorithm=aes-256, /ip ipsec proposal add name=ikev2-proposal enc-algorithms=aes-256-gcm pfs-group=none, then /ip ipsec peer add name=ikev2-peer exchange-mode=ike2 passive=yes certificate=server-cert profile=ikev2-profile.
6. Bind authentication: /ip ipsec identity add peer=ikev2-peer auth-method=digital-signature certificate=server-cert generate-policy=port-strict mode-config=ikev2-modecfg.
7. Allow the protocols in the firewall: UDP/500, UDP/4500, and ESP (IP protocol 50).
8. On the client (Windows, macOS, and iOS all have native IKEv2 support): import the .p12 client certificate and the CA certificate, then add a native IKEv2 VPN profile pointing at the router's WAN address.
9. Verify: /ip ipsec active-peers print once a client connects.

• The real cost of this option is the certificate infrastructure, not the IKEv2 config itself — you're now running a small CA, which means tracking expiry and having a real revocation plan (a stolen laptop needs its client cert revoked, not just its VPN password changed).
• Native OS clients are the payoff: no app to install on Windows, macOS, or iOS — they all speak IKEv2 out of the box, which matters in locked-down corporate environments that won't let users install third-party VPN apps.
• Revoking access means removing that user's identity/certificate reference, not just deleting a peer — plan your certificate CN scheme (e.g. one CN per user) so you can find the right one later.

L2TP/IPsec (legacy, pre-shared key)

1. Enable the server with an IPsec secret: /interface l2tp-server server set enabled=yes use-ipsec=yes ipsec-secret="<strong-psk>".
2. Create an address pool and point the default PPP profile at it: /ip pool add name=l2tp-pool ranges=10.30.0.10-10.30.0.100 then /ppp profile set default-encryption local-address=10.30.0.1 remote-address=l2tp-pool.
3. Add one PPP secret per user: /ppp secret add name=alice password="<strong-password>" service=l2tp profile=default-encryption.
4. Allow the protocols in the firewall: UDP/500, UDP/4500, UDP/1701, and ESP (IP protocol 50).
5. Clients connect with their OS's built-in L2TP/IPsec (PSK) VPN client — Windows, macOS, iOS, and Android all ship one natively, entering the router's address, the shared PSK, and their own username/password.
6. Verify: /ppp active print shows connected L2TP sessions.

• The whole appeal is zero extra software — every major OS has this client built in, which matters for a user you can't ask to install anything. The trade-off is real: it's the weakest crypto and the least modern option of the three.
• The IPsec secret is a single shared PSK for every user, not per-user — anyone who has it (or a former employee who wrote it down) can attempt to connect, so per-user protection depends entirely on the PPP username/password behind it.
• L2TP/IPsec is notoriously fussy behind other NAT devices (double-NAT, some hotel/coffee-shop Wi-Fi) — if a client can't connect from a specific network, this is usually why; WireGuard and IKEv2 don't have this problem.

IPsec dial-up with FortiClient (preferred today)

1. Create users/groups first under User & Authentication → User Definition / User Groups (or bind to LDAP/RADIUS) — the wizard needs a group to attach the tunnel to.
2. VPN → IPsec Wizard → Remote Access → *Client Options*: choose FortiClient.
3. Set the *Incoming Interface* (your WAN), *Authentication Method* (pre-shared key is simplest to start; certificate-based is stronger), and the *User Group* created above.
4. Set the *Client Address Range* — the pool of internal IPs handed to connecting clients.
5. The wizard auto-creates the phase 1/phase 2 config, the address objects, and both firewall policies (client→LAN and LAN→client) — review them under Policy & Objects → Firewall Policy rather than assuming they're correct.
6. Install FortiClient on each endpoint (the free FortiClient Connect edition covers basic VPN-only use) and either import a .conf exported from the FortiGate or manually point it at the WAN address with the same PSK/user group.
7. Verify: Dashboard → Network → IPsec widget, or diagnose vpn ike gateway list and diagnose vpn tunnel list.

• Use the wizard, not a manual build — the two auto-generated firewall policies (client→LAN and the return LAN→client) are exactly the pair people forget when building IPsec dial-up by hand, and a tunnel with phase 2 up but no policies looks broken while actually being fine.
• FortiClient's free tier covers basic connect-only VPN; central management, endpoint compliance (EMS), and some advanced features need a paid FortiClient/EMS licence — check what you actually need before assuming a purchase.
• Certificate-based authentication is meaningfully stronger than a shared PSK for a remote-access population and is worth the extra setup once you're past a handful of users.

SSL-VPN

1. Create users/groups first under User & Authentication → User Definition / User Groups (or bind to LDAP/RADIUS).
2. VPN → SSL-VPN Settings: set the listening interface and port (default 10443), attach a certificate (a real one — the default self-signed cert throws browser warnings at every client), the client *Address Range*, and whether tunnel mode is full or split.
3. VPN → SSL-VPN Portals: choose or build a portal (Tunnel Mode gives full client software access; Web Mode gives clientless bookmarks to specific internal web/RDP/VNC resources) and assign it to the user group.
4. Add the mandatory firewall policy from the ssl.root interface to your internal zone — the wizard for this one doesn't always create it for you, unlike the IPsec wizard.
5. Distribute the FortiClient VPN-only installer, or give web-mode users the portal URL directly (no client needed for Web Mode).
6. Verify: Dashboard → Network → SSL-VPN monitor, or execute vpn sslvpn list.

• Fortinet is steering customers away from SSL-VPN toward IPsec/FortiClient, and it has been removed or restricted on newer FortiOS releases and lower-end models — see the version notes below before building anything new on it.
• SSL-VPN has been the subject of several serious, actively exploited CVEs. If you must run it, keep firmware current, restrict source geography/IPs, and never leave it on the default port with a self-signed certificate.
• The firewall policy from the ssl.root interface to your internal zone is a separate, mandatory step that the SSL-VPN setup does not always create for you — check it explicitly.

WireGuard VPN Server (recommended)

1. Settings → VPN → VPN Server → Create New → WireGuard.
2. Set the VPN subnet (e.g. 10.40.0.0/24) and the listening port.
3. Add a peer: name it, and UniFi generates the key pair, a downloadable .conf, and a QR code for it automatically — you never see or handle raw keys.
4. Scan the QR code in the WireGuard app (phones) or import the .conf file (desktop) to connect.
5. Verify: the VPN Server page shows each peer's connection status and last handshake.

• The QR-code onboarding is the standout feature here — scan and connect, no manual key entry, no certificates. Fastest phone onboarding of any vendor on this site.
• Revoking access means deleting the peer from the VPN Server page; there's no separate user directory to manage.

OpenVPN

1. Settings → VPN → VPN Server → Create New → OpenVPN.
2. Set the VPN subnet, protocol (UDP/TCP), and port.
3. Add users — username/password or certificate-based, depending on controller version.
4. Download the generated .ovpn profile per user.
5. Users connect with the generic OpenVPN Connect app — UniFi has no branded OpenVPN client.
6. Verify: the VPN Server page lists connected OpenVPN clients.

• Slower to connect and heavier than WireGuard, but has broader legacy client and corporate-firewall compatibility if a site blocks unfamiliar UDP ports.
• No UniFi-branded client — users need the third-party OpenVPN Connect app, one more thing to walk a non-technical user through installing.

L2TP

1. Settings → VPN → VPN Server → Create New → L2TP.
2. Set the pre-shared key and the client address pool.
3. Add users (username/password) on the same screen.
4. Clients connect with their OS's built-in L2TP/IPsec VPN client — no app install needed.
5. Verify: the VPN Server page shows connected L2TP sessions.

• The weakest of the three built-in servers — offered mainly for compatibility with older devices or environments that can't run WireGuard/OpenVPN clients. Prefer WireGuard when you have a choice.
• Like any PSK-based L2TP/IPsec setup, the shared secret is common to all users; per-user protection comes from the username/password behind it, not the PSK itself.

Teleport (zero-config, cloud-brokered)

1. Settings → VPN → Teleport → enable it on the gateway you want to expose access through.
2. Generate an invite link (one-time or durable) for the person or device that needs access.
3. The user installs the WiFiman app and redeems the invite — no manual key exchange, no port forward, no certificate.
4. Manage or revoke access from the same Teleport page at any time.
5. Verify: the Teleport page lists connected/invited devices.

• Genuinely the easiest remote access of any vendor on this site — an invite link and the WiFiman app, nothing to configure on the client side at all.
• The trade-off is real: connectivity is brokered through Ubiquiti's cloud, so you're trusting their relay infrastructure and your gateway needs a working internet connection and a linked ui.com account — this is not a fully self-hosted option like the other three.

WireGuard (recommended)

1. Install the package: System → Package Manager → Available Packages → wireguard.
2. VPN → WireGuard → Tunnels → Add Tunnel: set a listen port and generate (or paste) the server key pair.
3. Interfaces → Interface Assignments: assign the new WireGuard tunnel as a real interface (e.g. OPT3) — it does nothing routable until it's assigned.
4. Back in VPN → WireGuard, add a peer per user: their public key and an Allowed IPs value (their tunnel address, e.g. 10.50.0.10/32).
5. Enable the WAN firewall rule for the WireGuard UDP port, and add rules on the new WireGuard interface tab to let clients reach the LAN.
6. Give each user the server's public key, your WAN address:port as endpoint, and their assigned tunnel address to build their own client config.
7. Verify: Status → WireGuard shows peer handshake times.

• The tunnel must be assigned as an interface before firewall rules and routing work properly — adding the tunnel alone under VPN → WireGuard is not enough, and this is the single most common reason a WireGuard peer connects but can't reach anything.
• Fast, modern, and minimal config once you know the assign-as-interface step — the actual peer/key management is simpler than OpenVPN's certificate machinery.

OpenVPN

1. VPN → OpenVPN → Wizards walks through creating a CA, a server certificate, user authentication (local, LDAP, or RADIUS), and the tunnel network settings, and offers to create the WAN firewall rule for you.
2. Add users under System → User Manager, with a certificate per user if you're using certificate auth.
3. Install the openvpn-client-export package (System → Package Manager) — it generates a ready-made bundled installer/config per user with the certificate already embedded, rather than making them assemble one by hand.
4. Add firewall rules on the OpenVPN interface tab to let connecting clients reach the LAN — the wizard's auto-created rule only covers the WAN side.
5. Distribute the exported installer/profile to each user; they connect with the standard OpenVPN client (or the platform-specific installer from client-export).
6. Verify: Status → OpenVPN shows connected clients.

• The wizard plus the client-export package is the smoothest self-hosted remote-access setup on this list — genuinely ready-made per-user installers, not just a raw .ovpn file to hand-configure.
• The wizard creates the WAN firewall rule but you still need rules on the OpenVPN interface tab to let clients reach the LAN. That second set is the one people miss.
• For MFA, bind OpenVPN authentication to RADIUS (e.g. an MFA provider) — pfSense CE has no built-in MFA of its own.

SSL VPN — NetExtender / Mobile Connect / WorkPlace (primary, modern)

1. Manage → Connectivity → VPN → SSL VPN → Server Settings: enable SSL VPN, choose the listening interface (typically the WAN/X1), confirm the port (default 4433), and set a Client Address Range for the pool handed to connecting clients.
2. Manage → Connectivity → VPN → SSL VPN → Client Settings: enable NetExtender, set session timeout, and configure DNS/WINS servers pushed to clients.
3. Manage → Connectivity → VPN → SSL VPN → Client Routes: add the internal networks that should be reachable through the tunnel — this is your split-tunnel list; anything not listed here simply isn't reachable via NetExtender.
4. Grant per-user access: Manage → System → Users → Local Users & Groups (or bind to LDAP/AD/RADIUS/SSO), then on each user or group's VPN Access tab, explicitly add the networks that user may reach. This is a separate permission layer from Client Routes and the step most often forgotten.
5. Users connect by browsing to https://<WAN-IP-or-FQDN>:4433 and downloading NetExtender (the full thick client, Windows/Mac/Linux), or by installing SonicWall Mobile Connect (free app, iOS/Android/Chromebook/Windows/Mac) for the same access on mobile. A clientless WorkPlace portal (bookmarks to specific internal web/RDP/VNC resources, no install) covers limited-access cases.
6. Check licensing: Manage → System → Licenses — the base appliance typically ships with only a couple of free concurrent SSL VPN client licenses; scaling beyond that needs an SSL VPN concurrent-user license upgrade.
7. Enable SonicWall's built-in one-time-password/TOTP or RADIUS-based two-factor for SSL VPN users under Manage → System → Users → Settings — public-facing SSL VPN portals are a frequent credential-stuffing target.
8. Verify: Manage → Connectivity → VPN → SSL VPN → Status lists active client sessions.

• Two access-control layers both have to be right: Client Routes (what's routed to the client at all) and the user/group's VPN Access list (what that specific user is permitted to reach). Getting only one right produces 'connects fine, can't reach anything' — a very common support ticket.
• NetExtender and Mobile Connect are SonicWall's own clients, not generic IPsec/OpenVPN/WireGuard clients — there's no option to bring your own standard VPN client for this path.
• Free/base-included SSL VPN licenses are limited (often just a couple of concurrent users per appliance) — budget for per-user licence upgrades for any real deployment size; this is one of the vendors here where the good remote-access option needs a paid license to scale past a token number of users.
• WorkPlace gives clientless, bookmark-based access to specific internal resources, not full network access — don't confuse it with NetExtender when scoping a requirement for 'connect like you're in the office.'

Global VPN Client (legacy IPsec, Windows-only)

1. Manage → Connectivity → VPN → Base Settings (naming varies by SonicOS UI generation): enable VPN, then edit the built-in WAN GroupVPN policy that SonicWall ships by default for GVC connections.
2. In WAN GroupVPN, set IKE using Preshared Secret with a strong group shared secret, and choose the IKE/IPsec proposal (encryption/authentication algorithms, DH group).
3. On the policy's Client tab, set the address pool clients receive (DHCP over VPN, or a fixed range) and the DNS/WINS servers to push.
4. Create/assign users under Manage → Users → Local Users (or LDAP/RADIUS) and set each user's or group's Access List — the networks they're allowed to reach through GVC.
5. Export the connection profile from the WAN GroupVPN policy (an .rcf file), or note the server address, group name, and shared secret for manual entry.
6. Install the Global VPN Client (Windows only) from mysonicwall.com or the support portal, then import the .rcf file or enter the connection details manually.
7. Users authenticate with username/password (XAUTH) on top of the group PSK to bring the tunnel up.
8. Verify: Manage → Connectivity → VPN → Active Tunnels on the appliance, or the client's own connection status.

• Windows-only — there is no GVC client for macOS, Linux, or mobile, which alone rules it out for most modern mixed-device environments.
• Draws from a separate license pool from SSL VPN — a site can be out of GVC licenses while SSL VPN licenses sit unused, or vice versa.
• This is legacy, and SonicWall is not investing further in it — treat it as an option for compatibility with an existing GVC deployment, not a choice for something new.
• Being IPsec-based rather than SSL-over-HTTPS, it's occasionally the more firewall-friendly option on networks with strict egress rules that already permit standard IPsec but block unfamiliar HTTPS ports — the one scenario where it's still the right pick.