How do you prevent a VPN from exposing your IP when it disconnects?

After some trial and error I found a solution to my problem:

In order to prevent all accidental or random disconnections from a VPN exposing your real IP, you must route all destinations to go through a fake gateway with the exception of your VPN IP.

To the network/computer experts:

Assuming the following:

Normal Default Gateway: 192.168.1.1
Unused Private IP: 192.168.1.222
OpenVPN Server IP: 1.2.3.4

Using cmd:

route -p add 0.0.0.0 mask 0.0.0.0 192.168.1.222 metric 2
route -p add 1.2.3.4 mask 255.255.255.255 192.168.1.1 metric 1

Then disable DCHP by giving the adapter a static IP address and using the unused private IP as a fake default gateway; thus blocking every connection but your OpenVPN's

For those who need a more step by step approach:

The first thing you will need to do is open the command prompt by holding the windows key (the button just right of the left Ctrl) and hit r, a dialog box will appear. type in "cmd" and press enter.

A black box should appear with some writing, this called the command prompt and all commands issued from here on out will be done in this black box.

The first thing is to figure out you the fake gateway must lie within the network interface. What is the "interface" ? Well in this case it is the private IP that was assigned to the computer, which seems to be 2 options given my "pre-OpenVPN" table either 127.0.0.1 or 192.168.1.108. I know from experience that 127.0.0.1 is a loopback IP, so it narrowed it down. However if I didn't know my IP address I could click run the windows key + r and type in cmd and press OK. A black box appears and type the CMD command ipconfig and get an output like:

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . :
        IP Address. . . . . . . . . . . . : 192.168.1.108
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.1.1

There it specifically tells me my IP Address and thus "interface" is 192.168.1.108, so my fake gateway had to be in the range 192.168.1.100 to 192.168.1.254, and cannot be already in use.

For instance, lets say I wanted to use the IP 192.168.1.101, to check if it's use I would issue the command ping 192.168.1.101 and if I get a reply like this:

Pinging 192.168.1.101 with 32 bytes of data:

Reply from 192.168.1.101: bytes=32 time=1ms TTL=64
Reply from 192.168.1.101: bytes=32 time=1ms TTL=64
Reply from 192.168.1.101: bytes=32 time=1ms TTL=64
Reply from 192.168.1.101: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.1.101:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms

It would indicate that the IP 192.168.1.101 is currently taken and I cannot use it for my fake gateway. So I decide to try IP 192.168.1.222 and I issue the same ping command: ping 192.168.1.222. If the response is as follows:

Pinging 192.168.1.222 with 32 bytes of data:
Reply from 192.168.1.100: Destination host unreachable.
Reply from 192.168.1.100: Destination host unreachable.
Reply from 192.168.1.100: Destination host unreachable.
Reply from 192.168.1.100: Destination host unreachable.

Ping statistics for 192.168.1.222:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Then I would have successfully found a private IP that is currently not in use and can use for my fake gateway. For the rest of reply I will use 192.168.1.222 as my fake gateway.

The next step is to send every single destination attempt to go through our fake gateway, and not the real one. We do that by issuing this command:

route -p add 0.0.0.0 mask 0.0.0.0 192.168.1.222 metric 2

the 0.0.0.0 mask 0.0.0.0 means "every single address" will be sent to gateway 192.168.1.222. The metric 2 part is assigning this route a priority of 2 - this is important because a priority (metric) of 1 will take precedence over a priority of 2.

Giving it a metric of 2 will put it at a higher priority than gateway assigned by your DHCP, which for me was 30. This means that every destination will attempt to go through gateway 192.168.1.222 and not the real gateway, essentially routing every connection you try to make to no where.

You can verify you did this correctly by issuing the ipconfig command again:

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . :
        IP Address. . . . . . . . . . . . : 192.168.1.108
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.1.222
                                            192.168.1.1

Notice this time we have 2 IP address listed under default gateway, not just one. Also note how our fake gateway is listed first (top) and the real gateway is listed second.

What this in turns means that also when we try to connect to our OpenVPN server IP, in this example 1.2.3.4 it will be routed to the fake gateway (192.168.1.222) and not allow us to connect. We don't want that. Therefore we must create another route that has a higher priority (lower metric) than 2, that says when connecting to our OpenVPN IP we want it to connect to the real gateway (192.168.1.1).

The first thing we want to do is confirm what the OpenVPN server is, we can do that by using the ping command again. Typically VPN providers will give you an address such as us.bestvpn.com to connect to, we need to figure out what IP address this url is an alias for, which is best done using the ping command, we issue:

ping us.bestvpn.com

and response should be something like

Pinging us.bestvpn.com [1.2.3.4] with 32 bytes of data where the IP address between the brackets is the IP address to the OpenVPN server. We will use 1.2.3.4 as the VPN server IP.

Now we must set it up so that this IP is routed to our real gateway, we do this by issuing:

route -p add 1.2.3.4 mask 255.255.255.255 192.168.1.1 metric 1

The metric of 1 will allow the route to take priority over the metric 2 we gave the fake gateway route. It is important to note that mask 255.255.255.255 means the exact IP 1.2.3.4 - which is true for my case but you may want to make the mask 255.255.255.0 which essentially tells it that any IP in the range of 1.2.3.0 to 1.2.3.254 will be routed to the real gateway. This is useful if your OpenVPN provider uses a range of IPs to connect to it.

Now we should be able to connect to the VPN like normal, and then once connected can browse all of the internet. Once you disconnect you will notice that it seems like it's not connecting and then all of sudden it does, with your REAL ip, what?! Why did it do this?

Well, it's my understanding that by default when DCHP is realizing that the gateway is going no where after so many seconds, it will attempt to try the secondary gateway, in this case your real gateway.

In order to prevent that from happening you must turn off DCHP by assigning a static IP, subnet mask, and gateway to your internet properties. An step by step picture tutorial on how to do that in XP, Vista, and 7.

Once you have completed that, connect to the VPN again, verify it still works, then connect. Try to connect to a site and wait a good 2-3 minutes to confirm that the won't load and you are all set.

That is how you can prevent a random VPN disconnect from exposing your real IP address.

If you are concerned about DNS and IP leaks in OpenVPN and need an easy and automatic way to prevent IP and DNS leaks while using OpenVPN, check out these two easy tools offered by www.openvpnchecker.com

1. OpenVPN Watchdog: http://openvpnchecker.com/

2. OpenVPN Firewall: http://openvpnchecker.com/firewall.htm Edit/Delete Message