Router VPN Client vs Server Mode: What Each One Enables
One router role sends your traffic to a remote exit, the other lets you back in. Read the menus, credentials and return path before enabling either.
You log into the router, open the VPN page, and find two tabs that look like the same feature described twice: one wants a profile file from somewhere else, the other wants you to generate certificates and pick a port. They are not two views of one setting. One role makes the router dial out, the other makes it answer, and a box can do both without either one helping the other. Here is how to read the menu and decide which side you are on before you enable anything.
Open the VPN menu and read the role names
Start with the section headings rather than the toggles. A tab labelled client or "connect to a VPN service" expects an imported profile, a configuration file, or a set of credentials issued by someone else. A tab labelled server expects you to create the identities, choose a protocol and a port, and usually export a profile for each device that will connect.
Treat the marketing line on the box as unverified until the menu matches it. "VPN supported" can mean a client, a server, a protocol pass-through helper that only forwards packets to a device behind the router, or a proprietary remote-access app with no standard profile at all. The firmware documentation is the only place that distinguishes those cases, and the model number on the sticker does not.
Client mode: your LAN leaves through someone else's exit
In client mode the router behaves like a laptop running a VPN app. It needs a compatible protocol, a profile or credentials from the remote operator, and a routing decision about which downstream devices use the tunnel. Many firmwares offer a policy list where you name the source addresses or interfaces that should be sent through the tunnel and leave the rest on the normal connection.
The part that fails silently is the remote side. The endpoint you connect to must forward internet traffic for you and provide a return path, which is a policy on the provider, not a setting on your router. A menu that only offers server mode cannot build this outward service no matter how it is configured, and a provider that only supports site-to-site links may connect the tunnel successfully while dropping everything you send through it.
Check the tunnel's DNS handling next. If the profile pushes a resolver, the router should hand that resolver to downstream clients; if it does not, clients keep using the ISP resolver and resolve names outside the tunnel even though the packets go inside. A quick check from a connected laptop: the address you see at an IP-echo page should be the exit, and the resolver address in use should be the one the tunnel supplied.
Server mode: someone else arrives in your LAN
Server mode reverses the direction. The router listens, the travelling device connects, and the router then decides which home resources that connection may reach. This is the role you want for a NAS, a lab machine, or a printer, and it has a precondition that the client role does not: something outside must be able to reach the listener.
That precondition is where most home setups stall. If the router sits behind the ISP's own gateway, the VPN port has to be forwarded from that gateway, or the router has to be put in a bridge or DMZ mode. Behind carrier-grade NAT there is no inbound port to forward at all, so the design has to change: an outbound tunnel from the router to a relay, a hosted endpoint, or a mesh product. A server that cannot be reached is not misconfigured, it is unreachable.
Identities differ by role as well. A household client profile that sends everything to a paid exit is one shared secret, while a server that admits three phones and a laptop needs four identities you can revoke separately. Certificates and keys are per device, and the router's export page should give you one file per device rather than one file for the household.
Check the exact implementation before you commit
Netgate's documentation on choosing a VPN role separates the roles this way, and it is worth reading the equivalent page for your firmware rather than inferring from the tab names. Look for three concrete facts: which protocols the client can speak, whether the server supports the protocol your devices use, and whether the routing policy covers source addresses, whole interfaces, or nothing at all.
Then look at the support boundary. A consumer router with a client tab but no policy list will send every device through the tunnel, which is fine for a streaming box and wrong for a work laptop that needs the office tunnel. A router with a server tab but a single shared profile is a reasonable lab tool and a poor choice for a family, because revoking one device means changing everyone's configuration.
Pick the role by where the traffic starts
| What you want | Role | What must be true |
|---|---|---|
| Household devices exit through a paid VPN | client | provider profile plus a working return path |
| Reach a NAS while travelling | server | reachable listener and per-device identities |
| Join two sites permanently | either, as a site-to-site pair | matching protocols and non-overlapping subnets |
| Only one laptop needs the tunnel | neither | run the client on the laptop instead |
Walk the chosen row end to end before you change anything else. Enable the role, connect one client, confirm the address it appears as, confirm which resolver it uses, and confirm the return path in the opposite direction. If the router also has a firewall page, check that the new interface is not blocked by a default rule that was written when the tunnel did not exist.
When both roles are available and the requirement is genuinely both, run them as separate features with separate documentation. One router can dial out for the television and accept a phone connection to the NAS at the same time, but the two policies must not share a subnet, a DNS setting, or a firewall zone, or the first change you make for one will break the other.