Access Server Gateway User: Routing a Client's Branch LAN

You can ping an OpenVPN client's tunnel address and still fail to reach any host on the LAN behind it. Access Server hands that client an address from the VPN pool, and a pool address is the only thing the server knows it owns. The branch prefix is a separate fact that has to be declared, and once it is declared, the packets still need a forwarder at the branch and a return path at headquarters. A route typed into the wrong place looks like a fix and changes nothing.

Two addresses, two different ownership claims

When a client connects, Access Server assigns it an address from the configured VPN pool, for example 10.90.0.0/24. That assignment is a lease for one host. Nothing in the connection says the same client also sits in front of 10.60.0.0/24, and the server will not guess: a LAN prefix is reachable through a specific client only if an administrator states it.

This is why adding a static route on some other machine does not work. The route says "send 10.60.0.0/24 to this address", but if the address belongs to a client that was never marked as a gateway, the server has no reason to deliver those packets to it, and the client's own stack may drop them on arrival. The declaration and the route are two halves of one mechanism, and neither half is sufficient.

What the gateway setting actually installs

In the Admin Web UI the declaration is a user property: enable Configure VPN gateway on the connector user and enter the real branch prefix in Network on the VPN client side. That user is authenticated like any other, so it needs a credential policy that fits an unattended device, and its auto-login profile is a secret rather than a convenience file.

Behind that checkbox, the server now treats the prefix as reachable through that client's pool address, and the routing configuration under Access Controls decides what other clients are told. That is the second half: the routes pushed to ordinary clients, and the access rules that permit traffic from the headquarters networks to client addresses and client subnets. Enable routing for the networks that should reach the branch, and keep the permitted network list as short as the design allows.

A Community-style configuration directive pasted into a generated file does not participate in this model. The product owns the routing table it pushes, and a hand-edited line is either overwritten at the next regeneration or ignored by the components that need it.

Complete both networks' return paths

Take a concrete plan: headquarters 10.40.0.0/24, branch 10.60.0.0/24, VPN pool 10.90.0.0/24, and Access Server reachable at a private address on the headquarters side. The headquarters router needs routes for the branch prefix and for the VPN pool, both pointing at Access Server. Without them, the tunnel carries the request and the reply leaves by the default gateway, which produces the classic half-open connection.

At the branch, the connector must forward packets that are not addressed to itself. That means IP forwarding on the connector's operating system plus a forwarding permission scoped to the tunnel and LAN interfaces; on Linux that is net.ipv4.ip_forward=1 together with the forward chain rules, on Windows it is routing and remote access with the same intent. Branch hosts then need a return path: either the connector is their default gateway, or the existing gateway carries specific routes for the headquarters and pool prefixes.

The connector's own routing table does not reconfigure every host on the branch LAN. If the hosts point at another router, that router is where the return routes belong, and it must also accept that the source address it sees is not a neighbour on the local subnet.

Read a failure as a path, not as a permission

Test in a fixed order. First a permitted service from Access Server to a branch host, then the same service from an ordinary headquarters host, then the reverse direction if the policy allows it. If the first test passes and the second fails, the pushed routes or the access rules are the problem. If both pass but replies never arrive, examine forwarding at the branch and the return route on the headquarters side.

A host firewall is the next suspect, because with routed access the destination sees a headquarters or pool address as the source. A rule written for the local subnet will not match, and the packet is dropped after the routing worked perfectly.

Two designs need more than this article's pattern. Overlapping prefixes between sites make the destination ambiguous and require renumbering or translation, and a clustered Access Server needs every node to have a working path to the branch connector rather than one node holding the route. Apply changes through the product's normal save and update path, reconnect the connector, and verify again from both ends; a full reboot of every machine is not part of the procedure.

The Access Server site-to-site tutorial lists the same settings in product order, which is worth following once before adapting the design to your own prefixes.