I resolved the issues I was having when using dhclient to assign an ip address to the vpn virtual adapter. My vpn client virtual adapter is named vpn_vpn. I found that modifying the routing table right right after connecting to the vpn server doesn't work as well as first creating a new route to the vpn server ip via the active network adapter gateway before using dhclient to get an ip address for the virtual vpn adapter. Formerly it was necessary to create a new default route, but by adding a route to the server before calling dhclient, the default routes are created automatically.
I created a simple script to automate this. It determines the hardware adapter on the fly, so it can be used when I connect using my cellphone adapter or when using wifi. I also show the script to disconnect and stop the vpn service.
#!/bin/bash
# start vpn service
sudo vpnclient start
sleep 1
# connect to client service, then connect to server, allow time for server
# to wake up
vpncmd localhost /client /CMD remoteenable
vpncmd localhost /client /CMD accountconnect accountname
sleep 10
# get vpn server ip
serverip="$(getent hosts server.whateverdomain.com | cut -d ' ' -f 1)"
echo Server IP is $serverip
sleep 1
# get active hardware adapter name
hwadapter="$(ip route | sed -n '1 p' | cut -d ' ' -f 5)"
echo Adapter name is $hwadapter
sleep 1
# get default gateway of cellphone NIC connection
dgw="$(ip neigh show dev $hwadapter nud reachable | cut -d ' ' -f 1)"
echo Default Gateway is $dgw
sleep 1
# create new route to vpn server via default gateway of active adapter
sudo ip route add $serverip/32 via $dgw dev $hwadapter
# get address assigned to virtual vpn adapter
sudo dhclient vpn_vpn
# set up ip forwarding
sudo sysctl -w net.ipv4.ip_forward=1
I've been doing more testing and tweaking of this script. I'm not sure every sleep command is required, but it works much better that what I had before.
Now that I've had a chance to test it more exhaustively, I have discovered one issue that may or may not arise, depending upon whether the local router gateway is the same as the vpn server's router gateway. In other words, if your local network segment is the same as your vpn server segment, there can be problems accessing the server shares or other machines within the vpn lan. This is easily solved, if you only have one or two machines you want to access on the vpn lan. Just add another route after the script runs; you will need to know the gateway of the vpn server. For example, if the local subnet is 192.168.0.0/24 and the vpn server lan segment is the same, your virtual vpn server adapter gateway is 192.168.40.1, your vpn server is at 192.168.0.100, and you want to access its shares, just add the following after the script runs:
$ sudo ip route add 192.168.0.100/32 via 192.168.40.1 dev vpn_vpn
This is only necessary if your local internet connection for the client happens to be on the same network segment as your vpn server lan.
Here is the script to close the vpn client down:
#!/bin/bash
# disconnect client account from server
vpncmd localhost /client /CMD accountdisconnect accountname
# stop vpn client service
sudo vpnclient stop
# stop ipv4 forwarding
sudo sysctl -w net.ipv4.ip_forward=0
source: Source