NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. Recommended (RouterOS 7.x): WireGuard — /interface wireguard add name=wg0 listen-port=13231, then add a peer per user with their public key and an allowed-address.
2. Assign an address: /ip address add address=10.10.0.1/24 interface=wg0 and allow UDP/13231 in the input chain.
3. Alternative: IKEv2 with certificates, or the legacy L2TP/IPsec via /interface l2tp-server server set enabled=yes plus /ppp secret users.
4. Verify: /interface wireguard peers print (check last-handshake).

Changed across versions

• 6.xNo WireGuard, ever. RouterOS 6 predates it entirely and it was never backported — L2TP/IPsec or IKEv2 are the only options on a v6 box.
• 7.0+WireGuard ships as a native interface type from RouterOS 7's first release (the kernel it's built on gained WireGuard support during the 7.0 beta cycle). It has been the recommended remote-access option for the entire 7.x line, not just recent builds.

Gotchas & notes

• WireGuard is the right answer on modern RouterOS — no licence, minimal config, and it works from any OS with the standard WireGuard client. There is no MikroTik-branded client for anything.
• 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.
• PPTP is still present in RouterOS and must not be used — it is cryptographically broken. L2TP/IPsec is acceptable but fiddly with NAT.
• For WireGuard, remember allowed-address on the router side is a routing statement, not an ACL — overlapping values between peers break routing.
• Add firewall rules to control what VPN clients can reach; a WireGuard interface with an IP is otherwise reachable to everything the router can route to.

Steps

1. Preferred today: IPsec dial-up with FortiClient — VPN → IPsec Wizard → Remote Access, pick FortiClient, set the user group and the client address range.
2. Or SSL-VPN: VPN → SSL-VPN Settings (listen interface/port, certificate, address range, split tunnel) plus VPN → SSL-VPN Portals and an ssl.root firewall policy from the SSL-VPN interface to your LAN.
3. Create users/groups first under User & Authentication → User Definition / User Groups (or bind to LDAP/RADIUS).
4. Verify: Dashboard → Network → SSL-VPN monitor, or execute vpn sslvpn list.

Changed across versions

• 7.4.8+SSL-VPN web and tunnel mode removed from GUI and CLI on entry-level G-series models (50G, 70G, 90G, and similar) — not just low-RAM units.
• 7.6.0 – 7.6.2SSL-VPN web and tunnel mode removed from GUI and CLI on any model with 2GB RAM or less; check with diagnose hardware sysinfo conserve. Existing configs are not upgraded and silently stop working after the update.
• 7.6.3+SSL-VPN tunnel mode is replaced by IPsec VPN across all FortiGate models, regardless of RAM — this is a platform-wide architecture change, not just a low-memory restriction. Plan to migrate to IPsec dial-up.
• 7.6.4+SSL-VPN web mode is rebranded Agentless VPN and remains unavailable on the low-memory/entry-level models affected above.

Gotchas & notes

• Fortinet is steering customers away from SSL-VPN toward IPsec/FortiClient, and SSL-VPN has been removed or restricted on newer FortiOS releases and lower-end models. Check whether your version and model still support it before designing around 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; the wizard creates it but a manual setup often misses it.
• FortiClient's free version covers basic VPN; features like central management and EMS require licensing — budget for it.
• Require MFA (FortiToken, or RADIUS to your IdP) on any remote-access VPN. FortiGate includes a small number of free FortiToken Mobile licences.

Steps

1. Settings → VPN → VPN Server → choose WireGuard VPN (recommended), OpenVPN, or L2TP.
2. Set the VPN network subnet and create client profiles; UniFi generates a downloadable config / QR code per client.
3. Or use Teleport (UniFi's zero-config remote access) — Settings → VPN → Teleport, then share an invite link to the WiFiman app.
4. Verify: the VPN page shows connected clients.

Gotchas & notes

• Teleport is genuinely the easiest remote access of any vendor here — an invite link, the WiFiman client, no certificates or keys to handle. The trade-off is Ubiquiti-brokered connectivity and dependence on their cloud.
• WireGuard VPN Server in UniFi generates per-client configs with QR codes, which makes onboarding phones trivial.
• No MFA and no directory integration on the built-in VPN servers — users are local entries or key-based peers. For an organisation that needs SSO/MFA, this is a real limitation.
• L2TP is offered and is the weakest option; prefer WireGuard.
• Firewall rules for VPN clients live in the normal firewall ruleset — VPN clients are not isolated by default and can typically reach everything routable.

Steps

1. Modern IOS-XE: FlexVPN / IKEv2 remote access with AnyConnect (Secure Client) — crypto ikev2 profile, crypto ikev2 authorization policy (pool, DNS, split-tunnel ACL), and a virtual-template interface.
2. Legacy: webvpn/SSL-VPN on IOS is deprecated and removed from newer releases.
3. AAA: aaa new-model → aaa authentication login VPN group radius → radius server ...
4. Verify: show crypto ikev2 sa, show crypto session

Gotchas & notes

• Remote-access VPN on an IOS router is the least appropriate choice of the six. Cisco's answer is ASA/FTD or Secure Client with ISE — a router-based FlexVPN setup is doable but complex and rarely the right design.
• AnyConnect / Cisco Secure Client requires per-user licensing (Plus/Apex/VPN Only). Unlike WireGuard on MikroTik or UniFi, this is a budget line item.
• IOS SSL-VPN (webvpn) is deprecated; do not build anything new on it.
• Set ip mtu/tcp adjust-mss on the virtual-template as with site-to-site, or large-packet traffic fails.
• If the environment already has a Cisco firewall, terminate remote access there instead of on the router.

Steps

1. Install the GlobalProtect licence (a Portal licence is free for basic single-gateway use; GlobalProtect Subscription is needed for advanced features).
2. Create a tunnel interface and zone, then Network → GlobalProtect → Gateways → Add (auth profile, tunnel interface, client IP pool, split tunnel).
3. Network → GlobalProtect → Portals → Add — the portal hands out the agent config.
4. Set up an Authentication Profile (LDAP/SAML/RADIUS) and a certificate for the portal/gateway, then security policies from the GlobalProtect zone.
5. Upload the GlobalProtect agent under Device → GlobalProtect Client. Commit.

Gotchas & notes

• A basic single-gateway GlobalProtect deployment does not need a paid subscription, but split-tunnel-by-application, HIP checks, IPv6, and mobile management do. Check which features you actually need before assuming a licence purchase.
• It is a multi-object build — portal, gateway, tunnel interface, zone, auth profile, certificate, policies — and missing any one produces an unhelpful client error. Follow the order above.
• Use SAML to your IdP so MFA comes for free; PAN-OS SAML integration is one of the better implementations here.
• The portal certificate must be trusted by clients (a public or internal CA cert), not self-signed, or every user sees a warning.
• GlobalProtect has had serious CVEs; keep PAN-OS patched and restrict portal exposure where possible.

Steps

1. Recommended: WireGuard — install the package (System → Package Manager), then VPN → WireGuard → add a tunnel, assign it as an interface, add peers, and add firewall rules.
2. Or OpenVPN: VPN → OpenVPN → Wizards walks through the CA, server certificate, user auth, and tunnel settings, and offers to create the firewall rule.
3. Install the openvpn-client-export package to hand users a ready-made bundled installer/config.
4. Add users under System → User Manager with certificates, or bind to LDAP/RADIUS.
5. Verify: Status → OpenVPN or Status → WireGuard.

Gotchas & notes

• The OpenVPN wizard plus the client-export package is the smoothest self-hosted remote-access setup on this list — it generates per-user installers with the certificate embedded.
• 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.
• WireGuard on pfSense needs the tunnel *assigned as an interface* before firewall rules and routing work properly — adding the tunnel alone is not enough.
• For MFA, bind OpenVPN auth to RADIUS (e.g. an MFA provider) — pfSense CE has no built-in MFA.
• Do not expose the webConfigurator to the internet as a substitute for VPN; put management behind the VPN instead.

Steps

1. Decide the client: NetExtender (SonicWall's own SSL VPN thick client for Windows/Mac/Linux) is the primary modern option; SonicWall Mobile Connect (free app for iOS/Android/Chromebook/Windows/Mac) covers mobile/BYOD; Global VPN Client (GVC), a legacy Windows-only IPsec client, still exists but SonicWall is steadily de-emphasizing it.
2. 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.
3. Manage → Connectivity → VPN → SSL VPN → Client Settings: enable NetExtender, set session timeout, and configure DNS/WINS servers pushed to clients.
4. 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.
5. 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.
6. Users connect by browsing to https://<WAN-IP-or-FQDN>:4433 and downloading NetExtender, or by installing SonicWall Mobile Connect for a similar experience on mobile OSes. A clientless WorkPlace portal (bookmarks to internal web/RDP/VNC resources) is also available for limited, no-install access.
7. Check licensing: Manage → System → Licenses — the base appliance typically ships with only a couple of free concurrent SSL VPN client licenses; scaling beyond that requires an SSL VPN concurrent-user license upgrade tied to the appliance.
8. Verify: Manage → Connectivity → VPN → SSL VPN → Status lists active client sessions. There is no CLI configuration surface for any of this.

Gotchas & notes

• 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 first-party option to bring your own VPN client for full-tunnel access, unlike vendors that support standard IKEv2/OpenVPN profiles.
• Free/base-included SSL VPN licenses are limited (often just a couple of concurrent users per appliance depending on model/bundle) — budget for per-user SSL VPN license upgrades for any real deployment size; this is one of the two vendors here where the good remote-access option needs a paid license to scale past a token number of users.
• Global VPN Client (legacy IPsec) is Windows-only, draws from its own separate license pool from SSL VPN, and is not the direction SonicWall is investing in — avoid starting new deployments on it.
• 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.'
• 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.
• All of this is GUI-only configuration; the E-CLI has no commands to create SSL VPN users, client routes, or portal settings, consistent with SonicOS's general CLI limitations.

Steps

1. Confirm the device is a supported Insight-managed router (e.g. BR500-class); the Client VPN feature does not exist on Insight-managed switches or on Orbi Pro APs without a dedicated router unit.
2. In the Insight Cloud Portal/App: select the router, go to VPN → Client VPN (labeled OpenVPN in some firmware) and toggle it on.
3. Set server parameters: listening port, protocol (UDP/TCP).
4. Under the same page, create local VPN user accounts (username/password) — these are a separate credential store from Insight admin logins.
5. For each user, download the generated .ovpn profile from the portal and distribute it to them.
6. Users install the free, generic OpenVPN Connect app (Windows/macOS/iOS/Android) and import the .ovpn file to connect — NETGEAR ships no branded client of its own.
7. Check routing scope in the same VPN screen — options are typically limited to "route all traffic" or "route only the office subnet," with no granular per-user split-tunnel policy.

Gotchas & notes

• No first-party NETGEAR VPN client exists — this platform relies entirely on the open-source OpenVPN Connect app. There's no SSL-VPN clientless web portal option either, unlike vendors that offer a browser-based fallback.
• There is no built-in MFA/RADIUS/LDAP hook for this feature as documented — authentication is just username/password against the router's local VPN user table, so treat the credentials as the only line of defense and rotate them like any shared secret.
• Feature availability is model-gated: it only shows up on Insight-managed routers with a physical router/gateway component. Orbi Pro mesh systems that are AP-only, and all Insight-managed switches, have no remote-access VPN option in the portal at all.
• Zero CLI on these devices means zero scripting — user provisioning, profile generation, and revocation are 100% manual through the portal/app; there's nothing to automate with SSH or an API call for this feature.