Can you please try to connect to the build VM over RDP and run this script manually? Note that environment variables from the build are not available in the RDP session, so you need to reset them manually. This experiment will help us rule out (or blame) networking issues. If it works in RDP, next step will be to check if all variables are correct during the build. If not, will concentrate on networking part of the problem.
I've tried using the method described in that article to connect over RDP but haven't had success making it work (even with the VPN connect turned off). I've double checked a few variables, but what's strange to me is the output seems to just die after the rasdial command is called without any more output of what went wrong.
Can you try to create a VPN connection in UI to see if this works?
If you could create test VPN user for me, I could investigate. You can make this conversation private or email to team at appveyor.com with VPN user and server details.
Also we can enable you to set build worker clouds, e.g. datacenters where build VM is being provisioned for you to check if some specific datacenter works. But for that we need your AppVeyor account name.
I did some research and I think that you are loosing the VM because connection is actually succeeded, but default gateway is being set to your VPN server private IP, so it is being lost for AppVeyor and public Internet in general because routing is broken.
Add the following to your Add-VpnConnection command: -SplitTunneling $true.
Also might be needed to add static route (with route add command) to 192.168.128.103 host.
Let us know if this helps.
P.S. To create VPN connection on AppVeyor with UI, you need to follow the same steps as on any Windows machine, using Control Panel > Network and Internet > Network and Sharing Center > Set up an new connection or network.
Regarding networking drive I would first ensure that IP routing works properly. I would do something like this route ADD 192.168.128.103 MASK 255.255.255.255 <VPN_SERVER_PRIVATE_IP> and then check that ping and tracert to 192.168.128.103 work properly (assuming that ICMP is allowed on VPN server and on target servers firewall).
VPN_SERVER_PRIVATE_IP can be tricky and not what it seems from the first look. You can check on your local machine by typing ipconfig and route print before and after VPN connection made without split tunneling. New default gateway appeared after connection was made is that IP.