yeah, welcome to the dark art of OpenVPN's builtin routing table mangler! It took me nearly a week to figure out exactly what it was doing when I did the loadbalancing thing, but once you've got the hang of it, you can get OpenVPN to do the dirty work above and beyond its call of duty of just setting up an encrypted tunnel for you.
As a basic crash course, for every tunnel, OVPN creates 2 gateways for each connection. In your case the local end of the tunnel is 10.1.0.6 and the server end of the tunnel is 10.1.0.5 (this is what 'topology net30' does in the PUSH REPLY message). The server then needs to hint to the client what the actual gateway is which also has to be in the 10.1.0.0/16 network (I assume this 10.1.0.1?), so it sets up a second gateway via a static route to 10.1.0.1 through 10.1.0.5. To route to 172.16.0.1 you need to add a third static route to the client so that it knows to send stuff to 172.16.0.0/12 through 10.1.0.1.
Thankfully OVPN can do this for you and manage for the lifetime of the tunnel, so add:
push "route 172.16.0.1 255.240.0.0 10.1.0.1"
to the advanced box in the server page so that the client then pulls this and sets up the route.
Force all client generated traffic through the tunnel' box on the server (equivalent to adding 'push "redirect-gateway def1"' to the server conf), and it will setup a further load of routes that overrides the 0.0.0.0 default network and pass all traffic through the tunnel.
