How to route to an additional separate gateway and subnet?

In some of the more complex setups there are additional gateways with behind them additional subnets. If the OpenVPN Access Server itself can ping that gateway but cannot reach the subnet behind it, then the most likely solution here is to add in the routing table of the operating system where the Access Server is installed a route that directs traffic intended for the target subnet through the additional gateway. If traffic is then possible between the OpenVPN Access Server and the target subnet, then VPN clients should also be able to reach that target network as long as you give them access using the fields in user and group permissions and use the NAT method to give VPN clients access. If you use routing then it may not work because the VPN client subnet may be unknown to the target subnet. If you want to use routing then you should also implement a route back to the VPN client subnet using the OpenVPN Access Server's IP address in your network as the gateway address. It will function as a gateway to the VPN client subnet automatically.

To give VPN clients access to the additional subnets you can simply specify in the fields where you give users and groups access to subnets on the Access Server the additional subnets you want them to be able to reach. The traffic will then follow a path that goes from OpenVPN client to OpenVPN Access Server, and in the routing table there it will find the correct gateway and send the traffic there. That gateway then delivers it to the correct subnet. Responses generated there should then find their way back via static routes or routing tables to the IP address of the OpenVPN Access Server, and that will then send it to the OpenVPN client.

As usual, routing must be symmetrical, so it must function in both directions equally.

In some of the more complex setups there are additional gateways with behind them additional subnets. If the OpenVPN Access Server itself can ping that gateway but cannot reach the subnet behind it, then the most likely solution here is to add in the routing table of the operating system where the Access Server is installed a route that directs traffic intended for the target subnet through the additional gateway. If traffic is then possible between the OpenVPN Access Server and the target subnet, then VPN clients should also be able to reach that target network as long as you give them access using the fields in user and group permissions and use the NAT method to give VPN clients access. If you use routing then it may not work because the VPN client subnet may be unknown to the target subnet. If you want to use routing then you should also implement a route back to the VPN client subnet using the OpenVPN Access Server's IP address in your network as the gateway address. It will function as a gateway to the VPN client subnet automatically.

To give VPN clients access to the additional subnets you can simply specify in the fields where you give users and groups access to subnets on the Access Server the additional subnets you want them to be able to reach. The traffic will then follow a path that goes from OpenVPN client to OpenVPN Access Server, and in the routing table there it will find the correct gateway and send the traffic there. That gateway then delivers it to the correct subnet. Responses generated there should then find their way back via static routes or routing tables to the IP address of the OpenVPN Access Server, and that will then send it to the OpenVPN client.

As usual, routing must be symmetrical, so it must function in both directions equally.