Shore Up
Two separate office buildings joined by a sealed underground pipe, with a matching pair of identical keys, one held at each end.
FirewallsSecurity

Configure a Site-to-Site VPN on a SonicWall (SonicOS 7)

Ketan Aagja6 min read
No ratings yet

Before you run this

This guide builds an IPsec site-to-site VPN between two SonicWall firewalls (or a SonicWall and a compatible third-party peer) so two private subnets can route to each other over the public internet. It changes live firewall configuration: it adds a VPN policy, address objects, and — automatically — access rules that permit traffic between the two networks. Getting the phase 1/phase 2 parameters or the local/remote networks wrong can break routing or expose a subnet you didn't intend to.

You do this in the SonicOS 7 web GUI as an administrator account (the built-in admin or an equivalent with full config rights). No shell or scripting is involved — for SonicWall the GUI is the procedure.

Because a bad VPN or access-rule change can affect production traffic:

  • Keep a second way in. Have the console/serial connection to the firewall available, or a management session from an interface/source that is not dependent on the tunnel you're about to build. A wrong access rule can lock you out.
  • Back up the running config first. Go to DEVICE | Settings | Firmware and Settings, and export a settings backup (and/or create a local backup) before you touch anything. That file is your rollback.
  • Do it in a maintenance window. Both ends must be configured; expect a short period where the tunnel is down or flapping while parameters are matched.
  • Rollback path: if the change misbehaves, you disable or delete the VPN policy (both are reversible — you can re-add it), or you restore the settings backup you just exported under DEVICE | Settings | Firmware and Settings.

Test the parameters against your peer's requirements before you enable the tunnel in production. If you have a spare/test SonicWall or a lab peer, prove the exact proposal set there first.

What I'm assuming

  • Two Gen7 SonicWall appliances running SonicOS 7 (7.0/7.1). Menu names below are from that version; SonicOS 6.5 puts these in different places.
  • Each side has a static public IP on its WAN, or at least one side does and the other is a known dynamic peer (I cover the static-both case; dynamic peers need Aggressive Mode / IKE IDs, noted below).
  • You control both ends and can set identical crypto on each, or you have the far end's exact settings in writing.
  • Example values you will replace:
    • Local (this firewall) LAN subnet: 192.168.10.0/24
    • Remote LAN subnet: 192.168.20.0/24
    • Remote peer WAN IP: 203.0.113.10
    • Pre-shared key: a long random secret you generate; use the same string on both ends.

The crypto proposal I use below is a mainstream, current-strength set: IKEv2, AES-256, SHA-256, DH Group 14, PFS on. Both ends must match exactly. If your peer only supports something older, match the peer — but confirm its docs, don't guess.

Step 1 — Create the address objects

Define the networks each end represents. On this firewall:

  1. Go to OBJECT | Match Objects | Addresses.
  2. Click +Add and create the local network object:
    • Name: Local-LAN (your label)
    • Zone Assignment: LAN
    • Type: Network
    • Network: 192.168.10.0, Netmask: 255.255.255.0
  3. Click +Add again and create the remote network object:
    • Name: Remote-Site-LAN
    • Zone Assignment: VPN
    • Type: Network
    • Network: 192.168.20.0, Netmask: 255.255.255.0

Doing this first keeps the VPN policy clean and reusable.

Step 2 — Create the VPN policy

  1. Go to NETWORK | IPSec VPN | Rules and Settings.
  2. Click +Add to open the VPN Policy dialog.

General tab:

  • Policy Type: Site to Site
  • Authentication Method: IKE using Preshared Secret
  • Name: something identifiable, e.g. VPN-to-BranchOffice
  • IPsec Primary Gateway Name or Address: 203.0.113.10 (the remote peer's WAN IP)
  • IPsec Secondary Gateway Name or Address: leave 0.0.0.0 unless the peer has a real secondary
  • Shared Secret / Confirm Shared Secret: paste your pre-shared key

If the remote end has a dynamic WAN IP, you set the primary gateway to 0.0.0.0 and use IKE IDs on the Local/Peer IKE ID fields. The exact ID type (Domain Name / Email) must match on both sides — check the SonicOS 7 admin guide section on VPNs with dynamically addressed peers rather than guessing the ID format.

Network tab:

  • Local Networks: choose Choose local network from list and select Local-LAN.
  • Remote Networks: choose Choose destination network from list and select Remote-Site-LAN.

Do not use "Any address" on both sides unless you specifically intend a default-route/tunnel-all design; that is a different topology with its own routing implications.

Proposals tab — set both phases to match the far end exactly:

  • IKE (Phase 1) Proposal
    • Exchange: IKEv2 Mode
    • DH Group: Group 14
    • Encryption: AES-256
    • Authentication: SHA256
    • Life Time (seconds): 28800
  • IPsec (Phase 2) Proposal
    • Protocol: ESP
    • Encryption: AES-256
    • Authentication: SHA256
    • Enable Perfect Forward Secrecy: checked, DH Group Group 14
    • Life Time (seconds): 3600

Advanced tab:

  • Enable Keep Alive if this firewall initiates the tunnel (typically the side with the static IP, or both if both are static).
  • Leave the other advanced options at their defaults unless the peer requires a change.

Click OK / Save.

Step 3 — Repeat on the far end (mirrored)

On the remote SonicWall, do the same, mirrored:

  • Its Local network = 192.168.20.0/24, its Remote network = 192.168.10.0/24.
  • Its Primary Gateway = this firewall's WAN IP.
  • Same pre-shared key, same proposals (IKEv2 / AES-256 / SHA-256 / Group 14 / PFS Group 14).

A mismatch in any single proposal field is the most common reason a tunnel never comes up.

Step 4 — Check the access rules

SonicOS 7 normally auto-creates the access rules that permit traffic between the LAN and VPN zones when you build the policy. Confirm them:

  1. Go to POLICY | Rules and Policies | Access Rules.
  2. Look at the LAN → VPN and VPN → LAN rules for entries covering your objects. Tighten these to specific services if your policy is to allow only certain traffic; the auto-added rules are permissive by default.

Verify it worked

  1. On NETWORK | IPSec VPN | Rules and Settings, the policy row shows a status indicator — green means the tunnel is negotiated and up. It usually needs traffic (or Keep Alive) to bring it up initially.
  2. Generate traffic across it: from a host on 192.168.10.0/24, ping a host on 192.168.20.0/24 (make sure that target host's own firewall allows ICMP).
  3. Check the logs under MONITOR for IKE phase 1 and phase 2 completion, and for any proposal-mismatch or no-proposal-chosen messages, which tell you exactly which parameter disagrees.
  4. Confirm you can reach the intended services, not just ping.

Undo / rollback

  • Disable temporarily: on NETWORK | IPSec VPN | Rules and Settings, uncheck the Enable box for the policy. This drops the tunnel without deleting your work.
  • Remove entirely: delete the VPN policy from the same page; then remove the Remote-Site-LAN address object if unused, and review Access Rules for any leftover VPN-zone rules.
  • Full restore: if something else went wrong, import the settings backup you exported in Before you run this under DEVICE | Settings | Firmware and Settings. The appliance reboots into the prior config.

For anything ambiguous — dynamic-peer IKE IDs, route-based (tunnel interface) VPNs, or interop specifics with a non-SonicWall peer — consult the SonicOS 7 Administration Guide, IPsec VPN section, on SonicWall's documentation site rather than guessing a field.

Written by
Ketan Aagja

Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.

More about the author →

Was this article helpful?

Tap a star — no sign-in needed.

Be the first to rate this article.

Related guides

FirewallsSecurity

Route-Based Site-to-Site IPsec VPN Between Two FortiGates

This guide builds a route-based IPsec tunnel between two FortiGate firewalls so the LAN behind Site A can reach the LAN behind Site B and vice versa. "Route-based" means each end gets a virtual tunnel interface, and you steer traffic into the tunnel with a static route plus firewall policies — the mainstream FortiOS approach for a permanent office-to-office link.

9 min read
Security

Set Up a Site-to-Site IPsec VPN on a Palo Alto Firewall

This guide builds a route-based site-to-site IPsec VPN on a Palo Alto firewall: an encrypted tunnel between your firewall and a remote peer so two private subnets can talk over the public internet. You configure it entirely as candidate configuration in the web GUI and make it live with a Commit .

7 min read
Security

Set Up a Site-to-Site VPN Community on Check Point (R81.20)

This guide builds a site-to-site IPsec VPN community in Check Point SmartConsole so traffic between two sites' encryption domains is tunnelled and encrypted. The main path assumes both peers are Check Point gateways managed by the same Management Server (SMS) on R81.20 ; I note where a third-party peer (an Interoperable Device ) differs.

7 min read
FirewallsSecurity

Create Access Rules and NAT Policies on a SonicWall (SonicOS 7)

This guide walks through publishing one internal server to the Internet on a SonicWall running SonicOS 7 (7.0/7.1) — creating the address and service objects, an inbound NAT policy that translates your public IP to the server's private IP, and the access rule that permits the traffic. On a SonicWall the "script" is the vendor's own web GUI, so there is nothing to paste into a shell.

6 min read