Give VPN Users Access to One Service, Not the Subnet

A contractor needs one internal web application and nothing else, and the easy answer is to give them a tunnel into the server subnet. That works until the day they scan it. The narrower design takes more thought, because reachability, routing and application permission are three separate controls that have to agree.

Write the requirement as a service, not a subnet

Start with the destination host, the protocol and the port, then add the user or device group that should reach it. Include the private DNS zone only if the application resolves a name, and include an identity provider only if the sign-in flow needs one. Everything else is a dependency you have not justified yet.

A subnet is an implementation detail of the network team, while a service is what the business asked for and the unit that can be reviewed and retired.

If the dependency list grows past three items, the application probably needs its own design conversation.

Route narrowly, but enforce elsewhere

A narrow route or selector tells the tunnel which packets to carry; it is not an authorization policy. The gateway filter, the destination host's firewall and the application's own permission model are where access is decided. A route covering one address is a good start, and it is not the control that stops a determined user. That separation is what lets you change the filter without redesigning the tunnel.

Conversely, a wide route with a strict filter can be legitimate, but only if everyone involved knows which one is doing the enforcement.

Document the enforcement point explicitly, or the next change will move it by accident.

Check the source the service actually sees

The target sees either the client's pool address or the gateway's address, depending on whether you translate. Host firewall rules and logs have to match the real source. If several users share a translated source, no per-user rule on that host can distinguish them, and that is a design constraint rather than a bug.

Choose translation deliberately: it simplifies routing and destroys source identity, which matters for audit and for per-user rules.

Write down which of the two you chose, next to the rule that depends on it.

Application authorization is not optional

Reaching a port does not grant a role. The application still needs its own login and its own permissions, because the network layer cannot express which records a user may edit. A service that trusts any request from the internal subnet converts a narrow tunnel into full access for one compromised credential. The tunnel decides who may open the socket, and the application decides what they may do with it.

This is where the narrow design pays off twice, since fewer reachable hosts means fewer places an application-level mistake can be exploited.

Keep the network rule and the application role in separate systems, and retire them separately.

Prove both the permitted and the denied path

Connect as the authorized user and perform one harmless representative operation, then try a destination that should be unreachable. A design that only tests the first half is not tested, and the denied test is the one that proves the design. Test a fresh session after each rule change, and look at the return path if requests arrive but replies do not.

Do not disable forwarding filters to make the acceptance test pass, because that changes the thing under test.

When the user no longer needs the service, retire the remote identity and the application role in their respective systems, and record both. The strongSwan forwarding guide covers the gateway side of the path.