VPN stops working

[Lt_Flash]

Good day again! I have the following problem - WinGate VPN connects to another VPN host, everythings work fine for a time, but then it just stops working - ping says "Request timed out" while WinGate shows that VPN connection up and running. I disconnect manually, then reconnect again and after a few tries connection reestablishes (WinGate shows that connection establishes each time, but ping test starts working after a few tries). And when such a failure happends I can't even ping public IP of remote host. I use VPN 1.2.3 and WinGate 5.2.3 and I don't want to set up WinGate 6 with VPN 2.0 at this time.

[Pascal]

Rather than asking the questions one at a time, just going to throw them all in there:

What does a tracert to the remote host return? (Even a node behind the VPN, would be good)

How are your remote client machines (Machines behind the VPN Server) discovering their routing information? Is this through a default gateway, static routes or using a RIP v 2 listener?

Do you have any networking to that machine, or is it just pings failing? (E.g. does \\machinename OR \\ip-address still work?)

Is the behavior different from either end of the VPN at that stage ? (Might help isolate an end of the VPN)

Is this behavior different depending on the machine you're trying to reach? (I.e. a client behind the vpn node or the vpn node itself)

Is this behavior different depending on the machine you're initiating this request from? (I.e. a client behind the vpn node or the vpn node itself)

[Lt_Flash]

What does a tracert to the remote host return? (Even a node behind the VPN, would be good)

Tracert shows "*" i.e. request timeout on first hop, if I trace from WinGate VPN client, or it shows only VPN client server, if I trace from machines in my network. Thus, it seems that WinGate VPN machine fails to ping remote host.

How are your remote client machines (Machines behind the VPN Server) discovering their routing information? Is this through a default gateway, static routes or using a RIP v 2 listener?

My client machines use default gateway in network, and that gateway has WinGate VPN client, which connects to other VPN hosts. And by the way that machine routes some packets to another router. For example, WinGate VPN keeps 192.168.2.0 and 192.168.4.0 networks, passing other 192.168.0.0 packets to another router. MS Routing is disabled, I just established static routes to that networks, which are not hosted by WinGate VPN. And of course, I have Routing and NAT enabled on WinGate.

Do you have any networking to that machine, or is it just pings failing? (E.g. does \\machinename OR \\ip-address still work?)

No, everything stops working, I can't even ping public IP of remote machine. I have an option "Allow remote computers to ping this machine from Internet" enabled on remote VPN host in firewall.

Is the behavior different from either end of the VPN at that stage ? (Might help isolate an end of the VPN)

I can't check another end, because it's end is in another cities...I set up everything there using MS Terminal Services.

Is this behavior different depending on the machine you're trying to reach? (I.e. a client behind the vpn node or the vpn node itself)

I can't reach either of remote machines. My typical remote configuration is a router and a server, and in some offices one or two additional computers. So, I use WinGate VPN to connect to router and then to reach other computers in remote network.

Is this behavior different depending on the machine you're initiating this request from? (I.e. a client behind the vpn node or the vpn node itself)

I can't reach remote computers either from VPN node and from local network.

PS. Pascal, thank you very much for your help, your answers are always fast and very helpful!

[Lt_Flash]

Well, maybe I found an error...In my routing table there was a route like this:

192.168.0.0 255.255.0.0 10.0.0.210 1

I don't know where did it come from, but maybe that was why everything go wrong...I will test for a while and tell you, if everything be ok...Sorry for disturbance and thanks for your help again...

[Lt_Flash]

No, it didn't help...So, the question is still open %)

[Pascal]

I find it odd that it works for a while and then stops working. That's why I asked about the RIP listener, I was wondering if it was maybe learning bogus routes over time and that it was causing it problems. But, since you're using the default gateway option, you probably have all the RIP checkboxes unticked anyway.

I'll need to talk to Genie tomorrow, see if he has any ideas - this might be control channel / driver related at the moment - so would be good to get a second opinion. Would it be possible for you to email me the route table of your end of the connection (Once established) and then a second copy thereof (When the problem has occured), please?

If possible, both the WinGate view (In Extended Networking) and the OS view (via route -print from a cmd prompt)

[Lt_Flash]

Well, I belive that the problem actually solved...It passed several hours since I delete wrong route 192.168.0.0 and written that message about "No, it's not". I restarted WinGate after that and it removed that route from it's routing table...Seems like it's ok from that time - everything work properly...Thank you very much, I will report if the problem rise again. Again, thank you for your help!

[Lt_Flash]

Good day...I'm terribly sorry to say, but my problem rise again...Routing tables unchanged before and after connect, but no traffic can go throw while WinGate shows that connection is up and running...Here's the pics:



Routing table:

[Lt_Flash]

So? Any ideas?

[adrien]

Hi

Sorry this post has not been answered for so long, are you still having this problem?

Which RIP options do you have selected in the general tab of the VPN settings?

Adrien