Most engineers think…
Most people think 'VPN on a firewall' means one thing — a site-to-site IPsec tunnel between two offices. That single mental model leaves you stuck the moment someone asks about a travelling laptop or a one-person retail kiosk.
A Sophos Firewall is really a VPN concentrator for several styles at once: site-to-site IPsec (policy-based or route-based) and SSL to join networks, remote access via Sophos Connect, SSL VPN, IPsec RA and clientless HTML5 bookmarks to bring users in, and SD-RED for a zero-touch branch. They all land in the same VPN zone, obey the same firewall rules, and sit behind the same MFA. Knowing which style fits which problem — and how phase 1 and phase 2 negotiate underneath — is what makes you useful in design reviews and in interviews.
① Site-to-site IPsec — policy-based vs route-based
A site-to-site VPN joins two networks with a permanent encrypted tunnel, so a host in one office reaches a host in the other as if they were on the same LAN. On Sophos Firewall the workhorse is IPsec, negotiated with IKEv2 (legacy IKEv1 is still supported). Each end is set to initiate (actively brings the tunnel up) or respond-only (waits for the peer) — a branch on a dynamic public IP normally initiates to a static-IP head office that responds.
Two designs, one choice
In a policy-based tunnel the firewall encrypts traffic that matches configured local and remote subnets — simple, but every new subnet means editing the list. In a route-based tunnel the connection becomes a virtual tunnel interface (xfrm) that you simply route traffic into. Route-based is preferred for scale and SD-WAN because you can run dynamic routing (OSPF/BGP/static) over the tunnel instead of maintaining subnet lists by hand.
If you expect more subnets, multiple sites, or any dynamic routing / SD-WAN, start with a route-based tunnel and its tunnel interface. You route traffic into the interface once instead of editing local/remote subnet lists every time the network changes.
Which site-to-site design exposes a tunnel interface and lets you run dynamic routing?
② IPsec profiles — phase 1, phase 2 and the classic mismatch
The thing that actually decides whether a tunnel comes up is the IPsec profile — the rulebook both ends must agree on. It is split into two phases. Phase 1 (IKE) authenticates the peers and builds a secure channel: it negotiates encryption, hashing, the Diffie-Hellman (DH) group and a key lifetime. Phase 2 (the IPsec SA) then negotiates the keys that actually encrypt your data, including encryption, an optional PFS DH group and its own lifetime.
The failure everyone hits
If phase 1 succeeds but phase 2 never establishes, the two ends almost always disagree on phase 2 crypto — a different encryption algorithm, DH group or PFS setting. The IPsec log shows 'no proposal chosen'. The fix is not to restart the box: open the IPsec profile on both firewalls and make encryption, DH group, PFS and key life identical, then re-initiate.
The tunnel becomes a virtual interface (xfrm) you route into — so you can run dynamic routing and scale for SD-WAN without editing subnet lists.
The phase 1 / phase 2 rulebook: encryption, DH group, PFS and lifetimes. Both ends must match exactly or the tunnel never establishes.
The recommended remote-access client for IPsec and SSL VPN — provisioned by .scx/.pro file or Sophos Central, with OTP and auto-connect.
A zero-touch Remote Ethernet Device (SD-RED 20/60) that auto-builds an encrypted tunnel back to the firewall, managed centrally with no local config.
Priya Nair at Kanira Retail in Kochi faces this
A new site-to-site IPsec tunnel between the Kochi head office (static IP) and the Coimbatore warehouse (dynamic IP) shows phase 1 up, but phase 2 never establishes — so no traffic flows between the sites.
The two ends use different phase 2 settings: the warehouse profile has PFS and a stronger DH group with AES-256, while the head-office profile has PFS off and AES-128. The phase 2 (IPsec SA) proposal is rejected.
In VPN ▸ IPsec connections the tunnel is green on phase 1 but has no child SA; the IPsec log viewer shows 'no proposal chosen' on phase 2.
Sophos Firewall ▸ VPN ▸ IPsec connections + Logs ▸ VPN (IPsec)Edit the IPsec profile so encryption, DH group, PFS and key life are identical on both firewalls, and confirm a firewall rule permits the VPN-zone subnets both ways.
Re-initiate the tunnel; phase 2 comes up, the IPsec log shows a child SA established, and a host in Kochi can reach a host in Coimbatore.
A tunnel shows phase 1 established but phase 2 never comes up. The single most likely cause is…
③ Remote access — Sophos Connect, SSL VPN, clientless and MFA
Bringing a single user's device inside the network uses a different toolkit. The recommended client is Sophos Connect: it supports both IPsec and SSL remote access, is provisioned by importing a .scx/.pro connection file or pushed via Sophos Central, and supports OTP/two-factor and auto-connect. There is also classic SSL VPN remote access (OpenVPN-based, with a downloadable client config), plain IPsec remote access, and — for the lightest touch — clientless access through the user portal.
Whichever style you pick, remote users land in the VPN zone, are authenticated against AD/LDAP/RADIUS, and should always sit behind MFA/OTP (Sophos Authenticator or a third-party app). The interview line: a stolen password alone must never be enough to walk into the network — MFA is the difference.
Standing up Sophos Connect or SSL VPN and skipping OTP/MFA is the classic security miss. A single phished or reused password then equals full network access. Bind remote access to AD/LDAP/RADIUS and require a second factor (Sophos Authenticator or third-party) before anyone lands in the VPN zone.
▶ Watch a remote worker connect with Sophos Connect
How a laptop gets inside end-to-end. Press Play for the healthy path, then Break it to see the classic failure.
Which is Sophos's recommended remote-access VPN client for users?
④ SD-RED zero-touch branches — and the pitfalls
For a tiny site with no on-site IT — a retail counter, a kiosk, a two-person office — a full site-to-site tunnel is overkill. The SD-RED (Remote Ethernet Device), in the SD-RED 20 and SD-RED 60 models, is a small zero-touch appliance: you plug it in, it phones home and builds an automatic encrypted tunnel back to the head-office firewall, and it is managed centrally with no local configuration. The branch effectively becomes another port on your firewall.
The pitfalls to dodge
Four traps catch people. A phase-1/phase-2 mismatch stops IPsec tunnels dead. A missing firewall rule for the VPN zone lets the tunnel come up but passes no traffic — green tunnel, no connectivity. Overlapping subnets on two joined sites need NAT-over-VPN to translate the clash. And leaving MFA off on remote access turns one phished password into full network access.
Don't close a VPN ticket because the tunnel shows up. Confirm a firewall rule actually permits the VPN-zone subnets in both directions, then test a real host-to-host reach. A tunnel can be perfectly established and still pass nothing if the rule is missing.
A two-person retail counter with no on-site IT needs to reach head office. Best fit?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: why is a Sophos Firewall called a VPN concentrator for several styles, not just a site-to-site box? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Site-to-site VPN
- A permanent encrypted tunnel joining two networks, so hosts on each side reach the other as if on one LAN.
- Route-based IPsec
- A site-to-site tunnel exposed as a virtual tunnel interface (xfrm) you route traffic into, enabling dynamic routing and SD-WAN scale.
- Policy-based IPsec
- A site-to-site tunnel that encrypts traffic matching configured local/remote subnets — simple but needs subnet-list edits per change.
- IPsec profile
- The phase 1 / phase 2 rulebook — encryption, DH group, PFS and lifetimes — that must match on both ends or the tunnel fails.
- Phase 1 / Phase 2
- Phase 1 builds the IKE SA (auth + key exchange); phase 2 builds the IPsec SA whose keys encrypt the data.
- PFS (Perfect Forward Secrecy)
- A fresh Diffie-Hellman key per session so a compromised key cannot decrypt previously captured traffic.
- Sophos Connect
- The recommended remote-access client for IPsec and SSL VPN, provisioned by .scx/.pro file or Sophos Central, with OTP support.
- Clientless access
- HTML5 bookmarks in the user portal that reach internal RDP/SSH/HTTPS/VNC hosts from a browser with no VPN client installed.
- SD-RED
- Remote Ethernet Device (SD-RED 20/60) — a zero-touch branch appliance that auto-tunnels back to the firewall, managed centrally.
- VPN zone & MFA
- The zone all VPN traffic lands in, governed by firewall rules and protected by a second factor (OTP/MFA).
📚 Sources
- Sophos Firewall — Site-to-site IPsec VPN: policy-based and route-based (tunnel interface). docs.sophos.com
- Sophos Firewall — IPsec profiles and IKE phase 1 / phase 2 settings (encryption, DH, PFS, lifetimes). docs.sophos.com
- Sophos — Sophos Connect client: remote access setup and provisioning (.scx/.pro, Sophos Central). docs.sophos.com
- Sophos Firewall — SSL VPN remote access and clientless (HTML5) user-portal access. docs.sophos.com
- Sophos — SD-RED (Remote Ethernet Device) deployment guide — SD-RED 20 / 60. docs.sophos.com
- Sophos Firewall — VPN multi-factor authentication (OTP) and authentication servers. docs.sophos.com
What's next?
Got VPNs mapped? Next, go up a level to Sophos Central — cloud management of all your firewalls, ZTNA as the modern replacement for remote-access VPN, and cloud reporting across the estate.