I just want to know if the VPN connection suddenly went down on Windows XP

[Tomos Davies]

I just want to know if the VPN connection suddenly went down on Windows XP.

It's too slow and too late to bring up a web browser to
whatismyipaddress.com and when I google for how to test the VPN connection,
all I get are DNS leak web sites.

Is there a command I can run constantly (like every few seconds) in WinXP
that will beep or pop up something when the VPN connection suddenly drops?

It's too late by the time I notice any Windows "Local Area Connection"
popups (most of the time they don't even happen or I'm not at the computer
when they do).

I'm wondering if a vpn-test program exists, or, if not, if there is a way
to string a "route print" command on the DOS command line?

I can "see" when a "route print" shows a VPN connection but how can I get
that to be automatic to beep or pop up a warning that the VPN just dropped?

[Paul[_32_]]

Tomos Davies wrote:
> In >, Tomos Davies opined:
>
>> I can "see" when a "route print" shows a VPN connection but how can I get
>> that to be automatic to beep or pop up a warning that the VPN just dropped?
>
> Is there an easy way to pop up a warning when VPN drops?
> Here's what a "route print" looks like off VPN and on VPN.
>

Find another kind of VPN ?

https://www.softether.org/4-docs/1-manual/4._SoftEther_VPN_Client_Manual/4.3_Virtual_Network_Adapter

Paul

[Tomos Davies]

In >, Paul opined:

> Find another kind of VPN ?
>
> https://www.softether.org/4-docs/1-manual/4._SoftEther_VPN_Client_Manual/4.3_Virtual_Network_Adapter

Hi Paul,
I thank you for the potentially helpful reply where I note with compliments
from lurking here that you tend to help a lot of people, which is noble.

The problem set has nothing to do with the VPN provider since any VPN would
be subject to the same problem, and, in fact, the more reliable the VPN,
the more pernicious the problem because the user will be lulled into a
sense of complacency.

Whether or not anyone realizes it, the problem exists on *all* VPNs.

The question is only how to detect the instant the VPN drops so that the
user can be alerted immediately, if not sooner, with a persistent and/or
audible alarm.

Do you think a DOS pseudo script like this can work?

1. Run the DOS route command every x seconds.
2. Look for a tell-tale indication of a vpn connection.
3. If there is no vpn connection, then sound an alarm.

Is there a better DOS command other than "route" for testing networks?

[Shadow]

On Thu, 6 Apr 2017 15:03:33 -0000 (UTC), Tomos Davies
> wrote:

>In >, Paul opined:
>
>> Find another kind of VPN ?
>>
>> https://www.softether.org/4-docs/1-manual/4._SoftEther_VPN_Client_Manual/4.3_Virtual_Network_Adapter
>
>Hi Paul,
>I thank you for the potentially helpful reply where I note with compliments
>from lurking here that you tend to help a lot of people, which is noble.
>
>The problem set has nothing to do with the VPN provider since any VPN would
>be subject to the same problem, and, in fact, the more reliable the VPN,
>the more pernicious the problem because the user will be lulled into a
>sense of complacency.
>
>Whether or not anyone realizes it, the problem exists on *all* VPNs.
>
>The question is only how to detect the instant the VPN drops so that the
>user can be alerted immediately, if not sooner, with a persistent and/or
>audible alarm.
>
>Do you think a DOS pseudo script like this can work?
>
>1. Run the DOS route command every x seconds.
>2. Look for a tell-tale indication of a vpn connection.
>3. If there is no vpn connection, then sound an alarm.
>
>Is there a better DOS command other than "route" for testing networks?

As an alternative, maybe you could configure your firewall to
deny ALL outside IPs other than your VPN's range ?
In theory, any connection will fail if the VPN falls.
It would also avoid DNS/Flash/Java etc leakage.
PS Don't use a VPN, so just a theory.
[]'s
--
Don't be evil - Google 2004
We have a new policy - Google 2012

[R.Wieser]

Tomos,

> Do you think a DOS pseudo script like this can work?
[snip]

You will not be alerted "the instant the VPN drops", but yes, it would.

> Is there a better DOS command other than "route" for testing
> networks?

Depends on what you call "better" and what you define as "testing the
network". But I could imagine using "netstat -a -n" and than look for
(IIRC) ":443".

Regards,
Rudy Wiesr


-- Origional message:
Tomos Davies > schreef in berichtnieuws
...
> In >, Paul opined:
>
> > Find another kind of VPN ?
> >
> >
https://www.softether.org/4-docs/1-manual/4._SoftEther_VPN_Client_Manual/4.3
_Virtual_Network_Adapter
>
> Hi Paul,
> I thank you for the potentially helpful reply where I note with
compliments
> from lurking here that you tend to help a lot of people, which is noble.
>
> The problem set has nothing to do with the VPN provider since any VPN
would
> be subject to the same problem, and, in fact, the more reliable the VPN,
> the more pernicious the problem because the user will be lulled into a
> sense of complacency.
>
> Whether or not anyone realizes it, the problem exists on *all* VPNs.
>
> The question is only how to detect the instant the VPN drops so that the
> user can be alerted immediately, if not sooner, with a persistent and/or
> audible alarm.
>
> Do you think a DOS pseudo script like this can work?
>
> 1. Run the DOS route command every x seconds.
> 2. Look for a tell-tale indication of a vpn connection.
> 3. If there is no vpn connection, then sound an alarm.
>
> Is there a better DOS command other than "route" for testing networks?

[Paul[_32_]]

Tomos Davies wrote:
> In >, Paul opined:
>
>> Find another kind of VPN ?
>>
>> https://www.softether.org/4-docs/1-manual/4._SoftEther_VPN_Client_Manual/4.3_Virtual_Network_Adapter
>
> Hi Paul,
> I thank you for the potentially helpful reply where I note with compliments
> from lurking here that you tend to help a lot of people, which is noble.
>
> The problem set has nothing to do with the VPN provider since any VPN would
> be subject to the same problem, and, in fact, the more reliable the VPN,
> the more pernicious the problem because the user will be lulled into a
> sense of complacency.
>
> Whether or not anyone realizes it, the problem exists on *all* VPNs.
>
> The question is only how to detect the instant the VPN drops so that the
> user can be alerted immediately, if not sooner, with a persistent and/or
> audible alarm.
>
> Do you think a DOS pseudo script like this can work?
>
> 1. Run the DOS route command every x seconds.
> 2. Look for a tell-tale indication of a vpn connection.
> 3. If there is no vpn connection, then sound an alarm.
>
> Is there a better DOS command other than "route" for testing networks?

The key distinction in the above link is:

"Messages Indicating that a Network Cable is Unplugged"

If you route all the traffic through the virtual adapter, and
don't allow any traffic at all to go to the physical adapter,
then leakage should stop. This is different than a VPN
on a physical adapter dropping, and the traffic flowing
over the physical layer again. At least it's a possible
way to manage the "VPN down" issue.

The virtual adapter idea, is potentially a cleaner
networking solution, not requiring bandaid scripts to work.

Paul

[Tomos Davies]

In >, Paul opined:

> The key distinction in the above link is:
> "Messages Indicating that a Network Cable is Unplugged"

Thanks Paul for indicating where to look in the URL.
When I first saw that URL, I wasn't sure what was the key point.
The associated paragraph is very confusing though.
"Messages Indicating that a Network Cable is Unplugged
When a VPN client uses a Virtual Network Adapter which
is not connected to a VPN, the adapter operates in exactly
the same state as when the network cable between a physical
network adapter and the switching hub is disconnected.
Therefore when a Virtual Network Adapter is used and a VPN
is not connected, Windows handles that Virtual Network Adapter
as a network adapter to which no network cable is attached.
When a VPN connection is established using Virtual Network
Adapter, the operation will start in the same fashion just
as when a network adapter is connected to a switching hub
by a network cable."

I have to (sheepishly) admit I am confused even as to what that was trying
to tell me. I'm out of my league because I got nothing from reading that.

> If you route all the traffic through the virtual adapter, and
> don't allow any traffic at all to go to the physical adapter,
> then leakage should stop.

I'm out of my league since I don't do anything overtly.
I just click on the VPN connection and that does all the "routing" for me.

> This is different than a VPN
> on a physical adapter dropping, and the traffic flowing
> over the physical layer again. At least it's a possible
> way to manage the "VPN down" issue.
>
> The virtual adapter idea, is potentially a cleaner
> networking solution, not requiring bandaid scripts to work.

I'm not sure I understand but I do appreciate the help.

Just to let you know, I just click on the VPN connection and all that
"virtual adapter" stuff just happens. Since I understood almost nothing in
this post, I think I'm out of my league.

[Shadow]

On Fri, 7 Apr 2017 01:57:21 -0000 (UTC), Tomos Davies
> wrote:

>In >, Shadow opined:
>
>> As an alternative, maybe you could configure your firewall to
>> deny ALL outside IPs other than your VPN's range ?
>
>I don't really understand that suggestion so allow me to explain that
>I don't explicitly use a "firewall" per se, although I have WinXP with
>ZoneAlarm wired to a Netgear SOHO router that is at default settings.
>
>To clarify which firewall of those two are you suggesting I modify?

Dunno, I use Kerio, which allows me to specify which ranges of
IP and which protocols are allowed in and out.
Make a rule to allow all TCP to and from your VPN's range of
IPs and further up a rule to disallow everything else (including ICMP
and UDP - someone just said VPN does not use UDP)
While you are connected to the VPN, traffic will be allowed,
but if the VPN goes down you will suddenly not be able to connect
anywhere. Which is as good as an alarm bell going off. Without the
bell.

You will have to tweak the rules.
Like I said, I don't use a VPN, so I can't do it for you, it's
just a theory.
[]'s
--
Don't be evil - Google 2004
We have a new policy - Google 2012

[J. P. Gilliver (John)[_4_]]

In message >, Tomos Davies
> writes:
>In >, Paul opined:
>
>> The key distinction in the above link is:
>> "Messages Indicating that a Network Cable is Unplugged"
>
>Thanks Paul for indicating where to look in the URL.
>When I first saw that URL, I wasn't sure what was the key point.
>The associated paragraph is very confusing though.
[]
>I have to (sheepishly) admit I am confused even as to what that was trying
>to tell me. I'm out of my league because I got nothing from reading that.
[]
It's certainly all way over mine!

I rather fear that there may be no solution to detecting _immediately_
when the VPN has failed, that wouldn't make it tedious to use. I
_presume_ - am I wrong here? - that (in the absence of any such
monitoring), the fact that a VPN connection _exists_ doesn't mean you
(or the other end) are actually sending anything over it all the time;
therefore, in order to "immediately" detect it has failed (I put that in
quotes as I'm sure you'd accept a momentary delay), any monitoring is
going to have to constantly do something over the link. I would imagine
- again, I may be wrong - that any such would introduce a momentary, but
noticeable, delay into the normal operation of the link. I have used
terminals where the echo (appearance on screen) of the characters I'm
typing isn't quite instant, and they're quite tedious to use; for the
"constant" monitoring to react soon enough, the (in effect) "ping"
packets would have to be frequent enough that they'd cause a noticeable
delay (and probably slightly variable, too, which would be even more
distracting).
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Madness takes its toll. Please have exact change
[via Penny Mayes )]