Network Security & VPN Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A VPN is a policy with a tunnel, not a tunnel with a hope

A VPN connects networks or people under a policy you wrote. The tunnel is the transport. The policy is who may send what. A tunnel that comes up and permits any source to any destination is a cable you cannot see, and it is usually a mistake. Write the source prefix, the destination prefix, and the ports before you write the crypto.

Site-to-site VPNs join prefixes. Remote-access VPNs join people, and the addresses those people get must not overlap the office prefixes they need to reach. If the office is 198.51.100.0/24 and the VPN pool is also 198.51.100.0/24, the client cannot tell the office from itself. Use a pool that is not routed at the user's home and not used in the office. Document it the way you document any other subnet.

IPsec, WireGuard, and TLS-based remote access are different mechanisms with the same planning questions. What are the peers? What are the keys or certificates, and where do they live? What prefixes are allowed? What happens when a peer is replaced? This page does not break tunnels and it does not collect credentials. It helps you plan a tunnel you are allowed to build.

The generators linked here can draft a WireGuard-style config or a policy sketch from values you type. They run in the browser. Replace every key and every placeholder. Do not ship a lab key to a branch. Review the allowed prefixes before the file leaves your machine.

Addressing that lets the tunnel work

Site A uses 198.51.100.0/24. Site B uses 198.51.101.0/24. The tunnel may carry those two prefixes to each other. It should not carry a default route unless you meant for one site to send the entire Internet to the other. A default over a VPN is a support model, a security model, and a capacity model. Name it if you want it. Omit it if you do not.

If both sites used 192.168.1.0/24 because the boxes arrived that way, the VPN cannot route between them until you renumber one. NAT at the tunnel is a patch for a numbering failure. Prefer renumbering the smaller site. The subnetting guide is the companion for that work. Overlap is not a crypto problem.

Remote users need a pool. 198.51.102.0/24 as a pool is fine in this documentation example when the office is not using it. The pool needs a route at the office toward the VPN gateway, and the client's allowed list needs the office prefixes the person may reach. An allowed list of 0.0.0.0/0 sends all client traffic into the tunnel. That may be what you want for a locked-down workforce. It is a surprise for a contractor who only needed one application. Choose it in the ticket.

DNS for remote users is part of the VPN. If internal names resolve only on the office resolvers, the client needs those resolvers while the tunnel is up, and must not keep them when the tunnel is down. A laptop that keeps an internal resolver on a coffee-shop network will fail open lookups or, worse, leak internal names into a question. Split the resolver behaviour with the tunnel state.

Keys, peers, and what you store

A WireGuard peer has a public key you can publish to the peer and a private key you do not. The tunnel file on disk is a secret because of that private key. Keep it out of tickets and out of git. The generator may show a placeholder. The placeholder is not a key you keep. Generate the real key on the system that will hold it, or inject it through a path you already trust.

IPsec peers often use a pre-shared secret or a certificate. A pre-shared secret in a ticket is a secret in too many inboxes. A certificate needs an expiry and an owner. Write the expiry next to the peer name. A tunnel that dies on a Saturday because a certificate expired on Friday is a calendar failure. Alerts on expiry are part of the design.

Identity for remote access should be a person, not a shared password taped to a firewall. The authentication server you already use is the right place. A local user on the firewall named vpn is a backdoor with a friendly name. Turn it off when the real directory works.

Replacement is the test. When a firewall is replaced, the peer address or the key changes. The other end must be updated in the same window. A tunnel with one end updated is down. Write both ends into the change. There is no such thing as a one-sided VPN change.

What the tunnel is allowed to carry

Start from deny. Allow the office prefix to the branch prefix for the applications you named, or allow the VPN pool to the application prefix. Do not allow any to any because the wizard offered it. A management protocol from the branch to every server is not a requirement of having a tunnel. SSH from a branch to a jump host is a requirement you can write in one line.

Logging the denies you care about tells you the policy is the thing that blocked the user, which is a better incident than a silent drop you discover after a week. Log the allows that are unusual, such as management, more carefully than you log every web session. The point is to notice a peer that starts talking to a prefix you did not name.

Split tunnelling and full tunnelling are both valid. Split sends only the office prefixes into the tunnel and lets the user's Internet go direct. Full sends everything to the office. Full gives you inspection and it costs you bandwidth and a dependence on the office path for a user's video call. Pick one in the ticket and test a web page and an internal application. If both go where you intended, the split is the one you configured. If both go to the office and you wanted split, the client is ignoring the list.

A tunnel is not a substitute for patching. A branch behind a VPN is still a branch. The hardening guide is the companion for the devices. The VPN guide only gets the packets there under a policy.

# Lab shape only. Replace keys and prefixes.
# Peer office, allowed 198.51.100.0/24
# Peer branch, allowed 198.51.101.0/24
# Do not use a placeholder key in production.
# Review before anyone commits this.

Bringing a tunnel up

Build the addressing first. Confirm the two prefixes do not overlap and that each side can route its own prefix to the VPN device. Then exchange public keys or certificates out of band. Then install the policy that is narrower than any-to-any. Then bring the tunnel up. Then test from a host, not from the firewall's own ping if that ping uses a different path.

Test the application, the name, and a prefix that must not work. The negative test is how you know the policy is present. A tunnel that can reach every internal subnet on day one will still be able to do that in a year, and nobody will remember that it was accidental.

Rollback is the previous peer config and the previous policy, saved before the change. Taking the firewall down is not the rollback. If the tunnel is the path you are using to manage the far firewall, make the change from a path that survives a bad tunnel, or have someone on site. Do not lock yourself out of the only door.

A worked pair of sites keeps the numbers boring on purpose. Office 198.51.100.0/24, branch 198.51.101.0/24, tunnel endpoints on addresses you own, allowed traffic only from the office prefix to the branch file server at 198.51.101.10 on the file-sharing port you named. The negative test is a client at the office trying to reach 198.51.101.20, a host that was not in the policy. That attempt must fail. If it succeeds, the policy is wider than the ticket and you do not add a second application to hide the mistake. You fix the policy.

Remote access for one contractor uses the pool 198.51.102.0/24 and an allowed list of the single application prefix, not the whole office. The contractor's home network is probably 192.168.0.0/24 or 192.168.1.0/24. Do not use those as the pool. The contractor's laptop must resolve the application name with the office resolver only while connected. Disconnect and confirm a public name still resolves and the internal name does not. That is the split you promised.

Keys stay out of the example. The page can show the shape of a peer and the prefixes. The private key is generated on the firewall or the host that will keep it. If a generator offers a placeholder, delete it and put the real material in through the vendor's own path. A tunnel that comes up with a key copied from a guide is a tunnel whose key is not a secret. Build it again.

Capacity of the tunnel is the capacity guide applied to the VPN path. A 100 megabit Internet circuit does not become larger because the VPN is up. If the branch will copy 10 gigabytes through the tunnel, compute the time before you promise it. Crypto overhead makes it a little slower than the raw circuit. The circuit is still the ceiling. Do not send a default route and a backup job through a branch circuit that was sized for mail.

Write both prefixes and prove they do not overlap.
Write the ports and the direction.
Decide split or full, and write the DNS behaviour.
Exchange keys or certificates out of band.
Install the narrow policy.
Bring the tunnel up and test one allowed flow and one denied flow.
Confirm you can still manage the far device if the tunnel fails.

Mistakes that make a tunnel you cannot live with

Overlapping site prefixes.

A remote-access pool taken from the office LAN.

Allowed IPs of 0.0.0.0/0 when the ticket said one application.

A private key in a ticket or a git repository.

A shared VPN password.

No expiry watch on a certificate.

Changing only one peer.

Testing only that the tunnel comes up, not that the wrong prefix is denied.

VPN checks before you call the peer done

Confirm this before you call the change done: The two prefixes are written and they do not overlap. The remote-access pool, if any, is not an office prefix and not a common home LAN you failed to consider. The allowed list matches the ticket and is not any-to-any. A negative test to a prefix that should fail has failed. Private keys are not in the ticket. Certificate expiry has an owner. DNS behaviour on connect and disconnect is tested. Both peers were updated in the same window. Management of the far device survives the tunnel going down. A second person read the allowed prefixes aloud. A negative test to a host outside the policy failed closed. The home-LAN prefixes 192.168.0.0/24 and 192.168.1.0/24 are not the remote-access pool. The tunnel ceiling is the Internet circuit, and a large copy was timed against it. And placeholder keys from any example were removed before the configuration was saved. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: Security: Server Hardening Guide.