VPN clients need addresses too, and the range they come from — the address pool — is invisible until the day it collides with something. Ten minutes of planning when you set up OpenVPN saves the strangest class of VPN bugs there is: the kind where everything connects and half of it works.
When the video reconnects at the end and checks that the client received a proper IP, that address came from the OpenVPN address pool: a private range the firewall keeps for VPN clients, separate from the office LAN. The Server settings hold this pool. Planning it well is not about the pool alone — it is about three ranges that must never overlap: the office LAN, the VPN pool, and the home networks of everyone who connects.
Routing is just the question "which way do I send this packet?", and it only has a clean answer when every destination range is distinct. Your office LAN holds the servers and printers. Your VPN pool holds connected laptops and phones — the firewall must see them as their own range so rules, reports and the Exported Networks logic can treat "came in by VPN" as a fact. And each employee's home LAN is a third network you do not control, which matters more than admins expect — see the next section. Give the pool its own range, in a different private family from the LAN (LAN on 192.168.x, pool on 172.16.x is a tidy habit), and the whole class of conflicts mostly designs itself away.
A huge share of home routers ship on 192.168.1.0/24 or 192.168.0.0/24 — and so do many small offices. When an employee connects from a home whose LAN matches the office LAN, their laptop holds two routes claiming the same range: the physical one under its feet and the tunnel to the office. In split tunnel, local addresses usually win, so office machines with twin addresses become unreachable or — worse — the user reaches a home device believing it is the office server. Symptoms look haunted: "VPN works from my brother's house but not mine." The permanent fixes are to plan the office LAN on a less default range (for example 192.168.10.0/24) when you build or renumber, or to give that specific user Full Tunnel, which forces traffic into the tunnel regardless. Best of all is never building a new office network on 192.168.1.0/24 again.
Each connected client consumes one pool address for the life of the session — a person with a laptop and a phone connected at once consumes two. Count the most people who will ever be connected at the same time, add devices, add a generous margin for growth and for the day everyone works from home because of rain, bandhs or a building power cut. A /24 pool (about 250 addresses) is comfortably large for a small office and costs nothing; a too-small pool fails in the rudest way, with the last person simply unable to connect while everyone else works. There is no prize for a tight pool.
One page in the office IT notebook: WAN address or DDNS name, LAN range, VPN pool range, which networks are exported, who holds profiles. Every future mystery — a new branch, a renumber, a "VPN broke after we changed the router" — gets solved in minutes with that page and in days without it. Address planning feels like paperwork precisely until the first conflict, after which it feels like prophecy.
Watch the video's final verification again — that assigned address the client receives is the pool doing its job.
▶️ Watch Full VideoNo. Keep them as separate ranges. The firewall treats VPN clients as their own source range for routing, rules and reports; merging the ranges creates ambiguous routes and half-working access that is miserable to debug.
One per simultaneous connection, not per employee. A laptop and phone connected together use two. Count your busiest realistic moment, then add generous headroom — a /24 pool is a safe default for a small office.
The classic cause is that their home router uses the same LAN range as your office, so their laptop cannot tell local from office addresses. Confirm their home range; the durable fixes are a less-default office LAN range or Full Tunnel for that user.