Losing the default route when disconnecting from Windows PPTP vpn

i don't know if you can address the bug itself somehow but a dumb batch script can help to circumvent it

start /WAIT ###command-that-starts-the-vpn###
route change 0.0.0.0 IP.OF.NORMAL.GW

I will have to look at the files in more detail, but my first guess is that you have your VPN client setting on that server setup to use the default gateway on remote network.

No, that was the first thing I checked. The checkbox for use default gateway on the remote network is unchecked.

If I can find a script that "fixes" the problem (I'm going to try the route change command after the VPN disconnects), I'm wondering if there is a way to run the "fix script" only if the VPN disconnects?

I did try that route change command, but as soon as I ran it, the network connection dropped and never came back

I suspect that if you ran that command after the VPN disconnected (as per the settings you posted) it would be unable to change the route because it doesn't exist.

Also, the syntax isn't quite right above, not sure if you fixed it but it needs to be the following to CHANGE the route back to the one described in your "before" config:

route change 0.0.0.0 mask 0.0.0.0 10.255.4.193

However, if I'm right above you actually need a route ADD command thus:

route add 0.0.0.0 mask 0.0.0.0 10.255.4.193

Incidentally, adding that route while it already exists will not cause any problems. You could just batch up the route add command and run it every 5 minutes or something. Or you could start to make it bit cleverer by outputting the routes (route print) and parsing the output for a 0.0.0.0 entry, then adding the correct one if 0.0.0.0 doesn't exist.

Let me know if you want to do that and I can write it up for you.

if you change the route to a previously working route, the network will not die.
try the route change before you use the vpn so you can check both the sytax and the gateway

---

I'm wondering if there is a way to run the "fix script" only if the VPN disconnects?

you are expected to run the script in order to launch the vpn. the route change will take effect after the vpn software is closed. does this fit your setup ?

---

@btassure : thanks for pointing out that the route may not exist.
simply enough, we can change the script to just both add and change the route
start /WAIT vpnX
route add default 10.255.4.193
route change default 10.255.4.193

the route add command will fail if the route already exists in which case the route change will do the job. the missing mask is not a syntax error. it is not required to use it.

----

just a thought but the problem you experience is likely related with the way the gateway is set in the first place. if you stick it in the routing table from the start instead of the interface (or the reverse), it is likely that your problem will disappear.

Well, I'm stumped. I wrote a script that runs the route add command every 10 seconds and then the route change command at the end of 60 seconds, disconnected the connection, and waited for 5 minutes. The connection never came back. The route add command, as intended, showed that the command failed while I was connected because the route already existed. Thanks for the help on this, it is difficult to troubleshoot when I'm not able to get back into that server to see WHY the connection has failed. Any other suggestions for me?

Hm, do you have any other servers on that EC2 instance? Or indeed, is it worth setting one up for a day or so to troubleshoot? You should still be able to get connections from the local network so if you had another server in the same subnet you could hop over to it from the working one?

Just to make sure.  You are using the standard Windows PPTP driver for your VPN?  Not some vendor specific (Juniper, Cisco) VPN client?


Also, is there any special reason why you are using the 169.254.0.0/16 subnet for your PPTP dial in?

Although I doubt it, this could be the cause, that subnet is a special subnet.  It is used when a host is setup for dhcp, but it receives no DHCP responses.

did you check that setting the gateway in a different manner worked (aka in the routing table VS in the parameters of the corresponding interface) ?

did you try running the 3 lines basic script i gave and redirect the output to a log file ? (without loops, waits or any similar stuff)

bump on  @giltjr : the 169... address is an autoconfiguration address that is picked because no address is set and  dhcp is either disabled or not answering. this might produce a route flush that the vpn software cannot setup back properly afterwards

Yes, using the standard Windows PPTP client. I was wondering if the DHCP might be the problem, as Amazon uses some weird method for obtaining a DHCP address. The DHCP server ends in a .0 address and (obviously) is not pingable. I wasn't sure if I could set a static LAN IP on Amazon's network without breaking anything.

I did try running the 3-line script, the two route commands showed "Parameter missing" when being run.

Thank you

Great, thanks. I will try this out tomorrow morning as it is already too late this morning to take the site down for testing.

Thanks again guys

Darn. The command runs and shows "OK" however, when I disconnect I still lose connection. After the VPN is started and I run the route add command, it says the route already exists.

Again, I am a bit concerned that you are getting a auto assigned IP address (169) when you connect to the VPN.   That is wrong.  What IP subnet should your VPN server be assigning when you connect to it?

It should be assigning a 10.13.1.x address which it is. I think the PPP dial in is the RAS service on that server. For some reason, I think the first text file I attached for configduringvpnconnection.txt was incorrect. It does not show the VPN client connection information in an ipconfig. I have attached a new file that does show the connection properly while connected to the vpn. Odd.
duringvpnconnection.txt

Although it is not 100% the same you may want to try the solution here:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016878

Darn. The command runs and shows "OK" however, when I disconnect I still lose connection. After the VPN is started and I run the route add command, it says the route already exists.

did you sick both the route add and route change commands in the script ?

you are NOT supposed to run the command after the VPN is started. it is supposed to be run after you disconnect from the VPN which is why i added the /wait flag.

if the VPN command exits before the vpn is closed the /wait flag is useless, and the workaround is not good. but it can be achieved by checking for the presence of the VPN link in a loop and issue the route whatever commands at that time

there may as well be a way to ask the vpn software to run a command when it is closed. you can also stick the script there.

what about initial routes creation ? did you try to switch from routing table to sticking the gateway in the interface config or the reverse ?

Yes, I had the route add and change commands in the script and had it run after the VPN was disconnected with no luck.

I'm not sure what you mean by your last sentence, could you elaborate for me please? Do you mean setting a static IP on my Amazon LAN adapter?

Thank you

not really. there are 2 ways to setup default routes on windows :
- setup the "default gateway" in the GUI configuration of one specific network card
- setup a static route for 0.0.0.0

whatever way you used, i believe trying the other one may help, and is a quick and easy test

---

i won't be able to help further with the script unless you copy-paste your script and the result of it's execution (error messages, your observation, and the resulting routes). "it does not work" does not describe much

Hi,

Thank you for all of the help, the solution is as follows:

I disabled the "INTERNAL" Dial-in RRAS adapter and set the IP address on the lan adapter to a static address. I am not able to disconnect from the VPN without any problems.

Thank you!

thanks a lot for posting back. best regards