Can Internet access via VPN be client dependent?

[BobAGI]

I am setting up an OpenVPN server (version OpenVPN 2.4.0 arm-unknown-linux-gnueabihf) for our company and now I have to find a way to allow or disallow the use of the remote gateway depending on client.
Some clients will use VPN while traveling to be able to browse the net as if they were in the office. So they need Internet to tunnel via VPN.

But some (like myself) who work remotely only want to have access to the office LAN resources via VPN, all else would go to the local ISP.

I have a very fast fiber but the speed at the office is much slower so I don't want to be slowed by Internet traffic going through the tunnel.
Can this be done server side or in the client OVPN file?
I have tried some client side configurations but to no avail.

[TinCanTech]

It can be done easily and it is all here:
HOWTO: For OpenVPN Community Edition

[BobAGI]

I did not find anything on that overview page.

But meanwhile I have set up an OpenVPN 2.4.0 server on Raspberry Pi3 and gotten it to work (finally).
While doing that I came across an interesting item concerning how systemd runs services on Linux:
One has to do two things to get the service running:
1) Edit the server.conf file to reflect how it should operate
2) Edit the /etc/default/openvpn file and add the name of the conf file to the AUTOSTART line:
The interesting point here is the comments in the file:

Code: Select all

# Start only these VPNs automatically via init script.
# Allowed values are "all", "none" or space separated list of
# names of the VPNs. If empty, "all" is assumed.
# The VPN name refers to the VPN configuration file name.
# i.e. "home" would be /etc/openvpn/home.conf
#
# If you're running systemd, changing this variable will
# require running "systemctl daemon-reload" followed by
# a restart of the openvpn service (if you removed entries
# you may have to stop those manually)
#
#AUTOSTART="all"
#AUTOSTART="none"
#AUTOSTART="home office"
#
# WARNING: If you're running systemd the rest of the
# options in this file are ignored.
#
# Refresh interval (in seconds) of default status files
# located in /var/run/openvpn.$NAME.status
# Defaults to 10, 0 disables status file generation
#
#STATUSREFRESH=10
#STATUSREFRESH=0
# Optional arguments to openvpn's command line
OPTARGS=""
#
# If you need openvpn running after sendsigs, i.e.
# to let umountnfs work over the vpn, set OMIT_SENDSIGS
# to 1 and include umountnfs as Required-Stop: in openvpn's
# init.d script (remember to run insserv after that)
#
OMIT_SENDSIGS=0

So it seems like one could place two conf files into /etc/openvpn/ one named server.conf and the other servernowebconf and configure them for different port numbers and server side networks (i.e. 10.8.0.0 and 10.8.1.0) and enable the line:

Code: Select all

push "redirect-gateway def1 bypass-dhcp"

only in the server.conf file.
Then one could set the default file entry:

Code: Select all

AUTOSTART="server servernoweb"

Would this not make the server listen on two ports and allow web browsing only on one while being the same in all other respects?
If so then one could have two copies of the cleint side ovpn file where only the port number differs!

Is this too good to be true?

[TinCanTech]

Or you can only push redirect-gateway to the clients you want to use your internet and not to the others ..

[BobAGI]

Do you mean to use the ccd functionality?
In the default conf file I found this:

Code: Select all

# To assign specific IP addresses to specific
# clients or if a connecting client has a private
# subnet behind it that should also have VPN access,
# use the subdirectory "ccd" for client-specific
# configuration files (see man page for more info).

# EXAMPLE: Suppose the client
# having the certificate common name "Thelonious"
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
;client-config-dir ccd
;route 192.168.40.128 255.255.255.248
# Then create a file ccd/Thelonious with this line:
#   iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious' private subnet to
# access the VPN.  This example will only work
# if you are routing, not bridging, i.e. you are
# using "dev tun" and "server" directives.

# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
# Then add this line to ccd/Thelonious:
#   ifconfig-push 10.9.0.1 10.9.0.2

Would it be possible to set it up like this:

Code: Select all

client-config-dir ccd

or should it be:

Code: Select all

client-config-dir /etc/openvpn/ccd

And then create a file /etc/openvpn/ccd/Thelonius
where I enter:

Code: Select all

push "redirect-gateway def1 bypass-dhcp"

while this line is commented out in the main server.conf file.

Will the result be that Thelonius is the only one able to browse the Internet while connected (at least using the tunnel for Internet traffic)?
But if most people would need the gateway redirect and only one or two the local network only?
It seems like this is not possible unless one could use a default ccd file for all or else have a command that unsets the redirect command...

[BobAGI]

If the server does not push a gateway redirect, then the client's gateway should remain but it seems not to do so.
I have now tested with a server which is configured to not push the redirect, yet when the client connects he loses his normal gateway to the internet even though a new such gateway is not provided by the OpenVPN server.
This looks wrong to me but is actually the case.
How could one fix this?

[BobAGI]

I found the problem finally!
When I was working on this I used an Android phone as my test client because I had no other client computer not attached to my local LAN.
And on the phone Internet is lost if I connect to a OpenVPN server where the redirect-gateway is commented out of the conf file.
So instead of using its own local gateway it can no longer access the Internet at all.
But now I managed to get a Windows7 PC on a different LAN for testing and now it works as one would assume!
So the problem was entirely on the testing client side (the Android Phone) where the latest version of the OpenVPN-Connect app was used.
Phones are probably best off using the full VPN tunnel rather than splitting it.

So my server has been functioning OK in this respect since yesterday, I did not know because I was using a bad test client....

[TinCanTech]

I don't know of any reason that a phone cannot do a split tunnel.

Anyway, pleased to hear you have your setup working now.

[BobAGI]

Yes, and it is running with two instances on the RPi3 server. One is on port 1198 and the other on 1199.
one is local LAN only and the other is with web also through the tunnel.