VPN client route gets stuck on server

[chespir]

hi all,

one more little cuestion, of course, concerning windows route handling. There is this pc (192.168.4.3) that connects from a 192.168.4.0/24 LAN to his VPN server on a 192.168.10.0/24 LAN. There´s no problem with the first connection, all pc´s on the server´s LAN appear on blue, services are reachable... The problem comes up when the VPN client connects again: there is this route 192.168.4.3 (his IP) that gets "stuck" on the server´s routing table, making it impossible for the client to reach any service on the VPN´s server LAN (PC´s appear grey until i clean the route with C:\route delete 192.168.4.3 -by hand.-)
IS there any way way to avoid this issue? Sure is some stupid detail i´m missing.

tnaks a lot, and as always, excuse my english.

[adrien]

Hi

Sounds like an issue with RIP.

Are you perhaps running the Qbik RIP client on either of those WinGate VPN machines?

From version 5.1 onwards, the RIP listener was built in, but it sounds like the OS learned of its own RIP routes from the other end of the VPN.

Does this route disappear by itself if you don't reconnect the VPN for more than 2 minutes or so?

Adrien

[chespir]

adrien you were right, qbik´s ripv2 was up and running! the funny thing is that i installed it about 2 or 3 months ago when i was heavily messing up with the vpn software, and i forgot about it till these days, when it started malfunctioning by some unknown reason, cause it didn´t show up till now.

Anyway i hope this was the reason, i´m expecting to see what happens from now on. I´ll post back if problems show up.

thanks a lot.

[adrien]

Hi

We found another problem which this could be attributed to as well.

WIth 5.1 and 5.2, we supported more fully ICMP error messages related to Path MTU discovery. This is where a machine finds out the maximum packet size it can send to another one, by way of ICMP error messages.

The way windows remembers what it learns by this method is by creating a route entry for the destination, and attaching the specific MTU for that host in the route entry.

With the VPN, if a remote client was communicating with a VPN server through it's local VPN gateway, then it is likely that such ICMP error messages would be sent by us up the stack to the VPN server machine. This in turn would create the route, which then if the remote VPN node disconnected and reconnected, would create a route clash, since the route created would be in the same subnet as the routes on the VPN client joining.

We have modified our checking for route clashes to take this into account, and will be releasing a new version soon (this week) to resolve these issues.

Adrien

[chespir]

One more doubt, could that be the same question of why does once in a while wingate vpn lose it´s published routes?

The are no routin conflict in here, because every vpn client connect from different subnets, but if dsl connection fails, sometimes vpn connection will never go up again, and it´s because vpn´s server "lost" their published routes. As you may remember my wingate server install is handling three eth´s, two of them in a subnet and the third one in another for firewalling purposes. The fact is that in "published routes" i have the chance of publishing twice the same subnetwork. Anyway i tried publishing it twice and once on every interface, but it does still lose routes.

About your answer, makes sense, because even if the ripv2 client was working, it never showed up till ver5.2 was installed.

thanks again