[VPN] Probleem met routering

[KorZijl]

Ik heb een probleem met de routering van een VPN-verbinding tussen een bijvestiging (subnet 10.0.1.0/24) en de centrale vestiging (subnet 10.0.2.0/24). Op de centrale vestiging staat onder andere een Exchange-server die vanaf alle clients op de bijvestiging beschikbaar moet zijn.

Even een korte schets:
Op de bijvestiging maakt een W2Kserver via RAS een VPN-verbinding met een W2Kserver op de centrale vestiging. Zowel op de bijvestiging als op de centrale vestiging zit het SDSL-modem in een switch geplugd en heeft de server een netwerkkaart waarop dat modem als default gateway staat ingesteld. Om het hele remote subnet te kunnen bereiken (en niet alleen de remote VPNclient), staat op de VPNserver onder ‘IP Routing’ de volgende static route: 10.0.1.0/24 via gateway 10.0.2.245
Bij bovenstaande route is de gateway het vaste ip-adres dat de VPNclient op de bijvestiging van de server krijgt. Tot zo ver werkt de routering prima en is er geen probleem.

Het probleem treedt op als om één of andere reden de bijvestiging zijn verbinding verliest en opnieuw een VPN opzet. De server accepteert deze verbinding, maar de routering naar het subnet van de bijvestiging wordt niet van kracht. Zodra je een adres in dat betreffende subnet wil pingen of tracen, wordt het pakket richting de default gateway van de VPNserver gestuurd, dus richting internet.
Als je in RAS dan de static route opent, de gateway wijzigt in iets onzinnigs, op OK klikt, de gateway weer instelt op 10.0.2.245 en weer op OK klikt, dan gaat de routering wél goed.
Het lijkt er dus op dat de static route naar het remote subnet moet worden ‘bevestigd’ na een reconnect om juist te werken.
Weet iemand hoe dat komt en – nog belangrijker – hoe dat te voorkomen is?

[KorZijl]

Even een schopje om dit topic weer onder de aandacht te brengen

[KorZijl]

Hmm, jammer dat niemand dit weet. Laatste schopje...

[njh]

KorZijl schreef op vrijdag 18 maart 2005 @ 18:00:
Ik heb een probleem met de routering van een VPN-verbinding tussen een bijvestiging (subnet 10.0.1.0/24) en de centrale vestiging (subnet 10.0.2.0/24). Op de centrale vestiging staat onder andere een Exchange-server die vanaf alle clients op de bijvestiging beschikbaar moet zijn.

Even een korte schets:
Op de bijvestiging maakt een W2Kserver via RAS een VPN-verbinding met een W2Kserver op de centrale vestiging. Zowel op de bijvestiging als op de centrale vestiging zit het SDSL-modem in een switch geplugd en heeft de server een netwerkkaart waarop dat modem als default gateway staat ingesteld. Om het hele remote subnet te kunnen bereiken (en niet alleen de remote VPNclient), staat op de VPNserver onder ‘IP Routing’ de volgende static route: 10.0.1.0/24 via gateway 10.0.2.245
Bij bovenstaande route is de gateway het vaste ip-adres dat de VPNclient op de bijvestiging van de server krijgt. Tot zo ver werkt de routering prima en is er geen probleem.

Het probleem treedt op als om één of andere reden de bijvestiging zijn verbinding verliest en opnieuw een VPN opzet. De server accepteert deze verbinding, maar de routering naar het subnet van de bijvestiging wordt niet van kracht. Zodra je een adres in dat betreffende subnet wil pingen of tracen, wordt het pakket richting de default gateway van de VPNserver gestuurd, dus richting internet.
Als je in RAS dan de static route opent, de gateway wijzigt in iets onzinnigs, op OK klikt, de gateway weer instelt op 10.0.2.245 en weer op OK klikt, dan gaat de routering wél goed.
Het lijkt er dus op dat de static route naar het remote subnet moet worden ‘bevestigd’ na een reconnect om juist te werken.
Weet iemand hoe dat komt en – nog belangrijker – hoe dat te voorkomen is?

ik heb wel een soortgelijk probleem gezien,
dat zat zo, na het verbreken van de verbinding gingen beide servers elkaar opnieuw benaderen, dit kan dus niet, er is altijd 1 partij die de verbinding maakt. (anders krijg je een "race" condition)

misschien kan je dat controleren?
succes!

[KorZijl]

Bedankt voor het meedenken, maar dat is helaas niet de oorzaak van het probleem.

[njh]

KorZijl schreef op maandag 04 april 2005 @ 20:42:
Bedankt voor het meedenken, maar dat is helaas niet de oorzaak van het probleem.

geen probleem,

komt de tot stand gebrachte verbinding te staan onder het kopje "remote access clients" in routing and remote access?

zoja is je config niet goed,
maar daar ga ik wel dieper op in als je antwoord hebt gegeven.

[KorZijl]

De verbinding komt inderdaad onder 'remote access clients' te staan, maar dat lijkt mij logisch.
Waarom m'n config dan volgens jou niet goed is kan ik niet helemaal volgen, maar ik laat me graag overtuigen

[vso]

KorZijl schreef op vrijdag 18 maart 2005 @ 18:00:
Het probleem treedt op als om één of andere reden de bijvestiging zijn verbinding verliest en opnieuw een VPN opzet. De server accepteert deze verbinding, maar de routering naar het subnet van de bijvestiging wordt niet van kracht. Zodra je een adres in dat betreffende subnet wil pingen of tracen, wordt het pakket richting de default gateway van de VPNserver gestuurd, dus richting internet.
Als je in RAS dan de static route opent, de gateway wijzigt in iets onzinnigs, op OK klikt, de gateway weer instelt op 10.0.2.245 en weer op OK klikt, dan gaat de routering wél goed.
Het lijkt er dus op dat de static route naar het remote subnet moet worden ‘bevestigd’ na een reconnect om juist te werken.
Weet iemand hoe dat komt en – nog belangrijker – hoe dat te voorkomen is?

als ik het begrijp is het de verbinding nadat hij verbroken is de gateway "wijzigt" zodanig dat je het handmatig elke keer moet aanpassen.

- als ik het goed begrijp is je VPN server ook je internet gateway,
- staat er wat in je eventlog zoiezo wat er gebeurdt en waarom hij de verbinding er uit knikkerd ?
- je stelt je static route in via het RRAS MMC ?

je zou een cmd console(dos scherm) kunnen openen op beide servers en dan het volgende kunnen doen.

code:

route add -p 10.0.x.0 mask 255.255.255.0. 10.0.y.254 Metric 1 IF ?

uitleg:
-p = geeft aan dat altijd zo is (ook als de verbinding er niet is)
x = dit is het subnet waar je naar toe wilt)
y = dit is het subnet waar je zit en hiermee geef je aan dat hij via dit adres naar het andere netwerk moet gaan
IF staat voor interface je hoeft het niet op te geven dan zoekt windows het zelf .

als je het via dos console doet en het werkt kan je de vpn eruit gooien... en dan kijken of de trace route nog steeds zijn werk doet .. hiermee bedoel ik dus testen door aantal situaties te simuleren!
zoals handmatig (opzettenlijk) de vpn verbreken en via het verlies van bv de internet verbinding

als dit allemaal niet werkt kan je als een ander red middel een script laten lopen (batch file) die om de x tijd de verbinding controleert is bv de route niet meer aanwezig dat hij deze dan zelf aanmaakt.


om te weten hoe het komt zal je meer informatie moeten geven ..maar ja daarin zal je de verbinding moeten monitoren
gebeurt het regelmatig ? de verbindingslog zal je aanmoeten leggen c.q controleren. nu is elk antwoord op de vragen
- hoe komt het?
- hoe los je het op?
- voorkom je het?
niet mogelijk om dat je een situatie schets geeft maar geen details / eventlog items of andere clue's
dus meer als dit kan ik je ook niet geven

[njh]

KorZijl schreef op woensdag 06 april 2005 @ 22:00:
De verbinding komt inderdaad onder 'remote access clients' te staan, maar dat lijkt mij logisch.
Waarom m'n config dan volgens jou niet goed is kan ik niet helemaal volgen, maar ik laat me graag overtuigen

ok, ik liep hier dus vorige week tegen aan toen ik een vpn tunnel aan het opbouwen was tussen 3 vestigingen.

als je een vpn tunnel bouwt (dus niet een windows xp machientje die via vpn een sessie begint) dan komt de bellende server niet bij remote access clients te staan, als dat wel het geval is, dan weet de partij die gebeld wordt niet dat de bellende partij een tunnel wil opbouwen, maar denkt dat het "gewoon" een client is.

ik heb een paar tutorials waar je wel mee uit de voeten moet komen, ik zal ze ff opzoeken


edit:
GEVONDEN
vpn tutorial

[ Voor 11% gewijzigd door njh op 08-04-2005 11:32 ]