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.