Cheap and Easy VPN Solutions

The problem in my case was that the server was assigning an IP address that was already in use to the remote access client. What clued me in that this was the problem was some warnings events seen in Event Viewer > Custom Views > Server Roles > Network Policy and Access Services.

The fix was to set up a static address pool of IPs that I knew were not in use. This is done on from the Routing and Remote Access Properties > IPv4 tab.

Things are a little bit clearer now. Of course OpenVPN has an option for your problem: If you want that the VPN client routes traffic for the network 1.2.3.0/25 through your VPN tunnel, use the option push (source) :

--push option
    Push a config file option back to the client for remote execution. Note that
 option must be enclosed in double quotes (""). The client must specify --pull in
 its config file. The set of options which can be pushed is limited by both
 feasibility and security. Some options such as those which would execute scripts
 are banned, since they would effectively allow a compromised server to execute
 arbitrary code on the client. Other options such as TLS or MTU parameters cannot
 be pushed because the client needs to know them before the connection to the
 server can be initiated. 

So, you have to add in your openvpn server configuration

push "route 1.2.3.0 255.255.255.128"

This tells the openvpn client, that it should route all traffic going to that subnet through the vpn tunnel. And, of course, on the server itself, the correct route must be in place, too - But I guess this route is probably already in place.

[UPDATE]
My answer is missing some basic information about routing. Any network device can act as a gateway - this is what home routers do. Routing is not done with iptables - that is a tool to modify the linux built-in kernel firewall. A routing decision is done with the help of the routing table (I will talk only about IPv4 here for briefity). For every IP packet which is being sent, the routing table is taken into account, starting with host-only routes ( /32 subnet), taking the most "precise" route it can find. So, the default route ( /0 subnet ) is taken only, if no matching route with a more "precise" subnet is being found.

Routing all traffic through the VPN tunnel is easy. OpenVPN uses the redirect-gateway directive for that. So either, you put that directive into all client configurations, or you put a

push "redirect-gateway def1"

into your server config. With the option def1, two routes with 128.0.0.0 subnets is being used instead of one 0.0.0.0 subnet route - which is being done to avoid that the new default route is being overwritten by the DHCP client.

Coming to the routes on your server. As the server is the endpoint of an IPSec tunnel (going to your partner), the software (strongswan?) already installed the necessary routes on that server, such that the traffic for the remote networks is being routed through the IPSec tunnel.

Let me draw a picture with example networks and routes for a better understanding. Think of the following network:

A ---------- B -------- C --------- D

• A is a OpenVPN client with ip 10.8.0.2
• B is the OpenVPN server with IP 10.8.0.1 and 172.16.0.1
• C is the remote IPSec endpoint inside your partner's network with the IP 172.16.0.2 and 192.168.0.1
• D is a network device inside the partner's network with the IP 192.168.0.10

in this example setup, you have three networks:

• the OpenVPN network
• the IPSec network
• the partner network

Device A has the route: 0.0.0.0/0 gw 10.8.0.1
Server B has two routes: one default gateway going to the ISP, and: 192.168.0.0/24 gw 172.16.0.2
Server C has two routes: one default gateway going to the partner's ISP, and: 10.8.0.0/24 gw 172.16.0.1
For Device D, only the default route 0.0.0.0/0 gw 192.168.0.1 is required.