diff --git a/Softether-using-vpncmd.md b/Softether-using-vpncmd.md
new file mode 100644
index 0000000..3bc1d57
--- /dev/null
+++ b/Softether-using-vpncmd.md
@@ -0,0 +1,66 @@
+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
+```
\ No newline at end of file