Win2K lastig routing probleem met VPN

[Verwijderd]

Hoi,

Ik heb 2 netwerken die fysiek gescheiden zijn. Het ene netwerk is 200.1.4.x met subnet 255.255.255.0 en het andere is 200.1.7.x met subnet 255.255.255.0.

Beide netwerken hebben een Windows 2000 DC server welke rechtstreeks via een kabel en een ADSL verbinding aan het internet verbonden zijn.

Het is de bedoeling dat beide servers verbinding met elkaar krijgen door middel van VPN (PPTP) via de breedbandige internetverbindingen.

Dit heb ik zojuist geconfigureerd in RRAS, bij beide een Routing interface toegevoegd (een Demand dial interface die persistent is, always on dus). Beide verbinding laten maken met elkaar en dat werkt perfect. Bij IP routing heb ik nog op beide servers een static route toegevoegd (bij het 200.1.4.x netwerk heb ik dus 200.1.7.x toegevoegd met als interface de Demand dial interface en vice versa). Ik kan nu vanaf de server uit 200.1.4.x netjes het volledige netwerk 200.1.7.x benaderen en omgekeerd.

Wat echter NIET lukt is het volgende: als ik vanaf een client PC in het netwerk 200.1.7.x een PC of server in het 200.1.4.x netwerk probeer te benaderen, dan gaat dat goed. Het ENIGE wat niet goed gaat is dat ik de VPN router in het 200.1.4.x domein (die Win2K server met RRAS dus) NIET kan benaderen. Ik kan dus alles bereiken in het 200.1.4.x netwerk BEHALVE de server waar de VPN connectie vanuit mijn netwerk mee is opgebouwd. Kan hem niet pingen dus, alle andere machines is geen probleem. Als ik dit probeer vanaf de server van 200.1.7.x, dan werkt het wel goed, maar elke andere machine hier in het netwerk kan deze 200.1.4.x server niet bereiken.

Omgekeerd is dit ook het geval, vanaf de server van 200.1.4.x kan ik netjes de server van 200.1.7.x bereiken (deze hebben immers rechtstreekse verbinding met elkaar via VPN) en ook de rest van het 200.1.7.x netwerk is gewoon te bereiken. Als ik het nu vanaf een andere machine uit het 200.1.4.x netwerk probeer kan ik alles bereiken BEHALVE de server van 200.1.7.x.

Ik hoop dat het duidelijk is... gaat in de routing dus iets mis maar zou even niet weten hoe ik dit oplos? Wie weet het wel?

Bedankt!!

[Verwijderd]

Update:

Iets vreemds! Hij doet het nu SOMS wel. Als ik vanaf een werkstation in 200.1.7.x ping naar 200.1.4.5 (= de server in het 200.1.4.x netwerk) gaat het 9 vd 10 keer mis maar soms ook ineens heel ff goed???

Pinging 200.1.4.5 with 32 bytes of data:

Reply from 200.1.4.5: bytes=32 time=53ms TTL=127
Reply from 200.1.4.5: bytes=32 time=51ms TTL=127
Reply from 200.1.4.5: bytes=32 time=50ms TTL=127
Request timed out.

Nu vind ik het nog vreemder? Hoe kan zoiets? Ik heb het direct na deze keer (hierboven) nog een keer getest en kreeg toen weer allemaal request timeouts.

Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 200.1.4.5: bytes=32 time=55ms TTL=127
Reply from 200.1.4.5: bytes=32 time=48ms TTL=127
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Vreemd toch? Constant timeout maar soms ook weer ff lekker vlot? Andersom (vanaf die server waar ik heen ping naar het werkstation waarvanaf ik ping is geen enkel probleem, gaat perfect)

[Arno]

200.1.4.0/24 en 200.1.7.0/24 zijn geen private ranges. Zijn deze wel van jou/jouw bedrijf

Zo nee, kan dat wel wat problemen opleveren.

[Flyduck]

je kan de VPN server toch ook benaderen op het IP adres dat hij heeft gehad van de de andere server (uit een static pool of via DHCP). Is dus meestal adres uit dezelfde range als het netwerk vanaf waar je een ping doet..

[Verwijderd]

Er is een reden voor die IP ranges (bepaald erg belangrijk pakket van hen schijnt beslist deze ranges te willen , vraag me ook niet waarom, was al zo voordat ik hier kwam) en RRAS plus ISA is verder wel geconfigureerd dat hij deze ranges als internal beschouwd (en verkeer hierheen dus niet internet opstuurt).

Idd zou ik hem op dat adres kunnen benaderen maar ik vind het zo vreemd dat het niet op zijn oorspronkelijke adres wil?? Moet toch kunnen lijkt me...

[Verwijderd]

Flyduck schreef op 31 oktober 2002 @ 22:17:
je kan de VPN server toch ook benaderen op het IP adres dat hij heeft gehad van de de andere server (uit een static pool of via DHCP). Is dus meestal adres uit dezelfde range als het netwerk vanaf waar je een ping doet..

Net getest en dat werkt dus ook niet, niet benaderbaar. Hij krijgt 200.1.7.247 maar deze kan ik niet pingen.

[Verwijderd]

Even voor de update ....

# ARIN Whois database, last updated 2002-11-01 19:05

OrgName: Latin American and Caribbean IP address Regional Registry
OrgID: LNIC

NetRange: 200.0.0.0 - 200.255.255.255
CIDR: 200.0.0.0/8
NetName: LACNIC-200
NetHandle: NET-200-0-0-0-1
Parent:
NetType: Direct Allocation
NameServer: ARROWROOT.ARIN.NET
NameServer: BUCHU.ARIN.NET
NameServer: CHIA.ARIN.NET
NameServer: DILL.ARIN.NET
NameServer: NS.LACNIC.ORG
NameServer: NS.DNS.BR
NameServer: NS2.DNS.BR
Comment:
This IP address range has been transferred to LACNIC for administrative
oversight. Please see http://www.lacnic.net/ for further details,
or check the WHOIS server located at whois.lacnic.net
Updated: 2002-08-16

TechHandle: LACNIC-ARIN
TechName: Latin American and Caribbean IP address Regional R
TechPhone: ([phone]
TechEmail: [e-mail]

OrgTechHandle: LACNIC-ARIN
OrgTechName: Latin American and Caribbean IP address Regional R
OrgTechPhone: ([phone]
OrgTechEmail: [e-mail]

# ARIN Whois database, last updated 2002-11-01 19:05

ik bedoel maar

[Verwijderd]

In principe zou de range er niet zo heel veel toe moeten doen.

Hoe ziet de routing-tabel er op de bewuste server uit?

[arikkert]

ik ken geen RRAS, maar kan zijn dat die vpn implementatie wel als "feature" heeft dat de vpn server zelf niet te bereiken is. ik kan me nl ook voorstellen dat er vraag is voor een zegmaar vpn-only server.
misschien vinkje toevoegen/verwijderen.

[Flyduck]

Verwijderd schreef op 02 november 2002 @ 16:15:

This IP address range has been transferred to LACNIC for administrative
oversight. Please see http://www.lacnic.net/ for further details,
or check the WHOIS server located at whois.lacnic.net
Updated: 2002-08-16

TechHandle: LACNIC-ARIN
TechName: Latin American and Caribbean IP address Regional R
TechPhone: ([phone]
TechEmail: [e-mail]

OrgTechHandle: LACNIC-ARIN
OrgTechName: Latin American and Caribbean IP address Regional R
OrgTechPhone: ([phone]
OrgTechEmail: [e-mail]

# ARIN Whois database, last updated 2002-11-01 19:05

ik bedoel maar

Het feit dat deze ip reeks al op internet gebruikt wordt maakt niet veel uit zolang je verkeer intern blijft. Het kan alleen problemen opleveren als je bv een website wil oproepen die dezelfde reeks gebruikt als je interne netwerk...

[Verwijderd]

Het is opgelost! Het bleek te liggen aan een fout in de ISA server LAT, de firewall verslikte zich vreemd genoeg erover als ik de adressen van het 200.1.7.x netwerk in de LAT van de ISA server op het 200.1.4.x zette (omdat hij beide als lokaal dient te beschouwen naar mijn mening en dus geen packet filters dient toe te passen op dit verkeer tussen de 2 netwerken). Ik heb deze 200.1.7.x range uit de LAT gehaald en toen werkte het ineens perfect en kon ik netjes alles bereiken!

In ieder geval bedankt voor alle hulp.

[BlaTieBla]

Flyduck schreef op 03 november 2002 @ 16:11:
[...]


Het feit dat deze ip reeks al op internet gebruikt wordt maakt niet veel uit zolang je verkeer intern blijft. Het kan alleen problemen opleveren als je bv een website wil oproepen die dezelfde reeks gebruikt als je interne netwerk...

Desalniettemin, getuigt het niet echt van inzicht.
Die private address-space is er niet voor niets. Gewoon gebruiken die reeksen.
De volgende posting kan heel goed gaan over een netwerktool, wat niet werkt, omdat het bijv. alleen met private adressen wil werken.

[Verwijderd]

BlaTieBla schreef op 04 november 2002 @ 11:03:
[...]


Desalniettemin, getuigt het niet echt van inzicht.
Die private address-space is er niet voor niets. Gewoon gebruiken die reeksen.
De volgende posting kan heel goed gaan over een netwerktool, wat niet werkt, omdat het bijv. alleen met private adressen wil werken.

Ik ben dat volledig met je eens maar in dit geval had ik daar geen controle over. Die reeksen waren er al en waren beslist noodzakelijk voor 1 belangrijk pakket wat men gebruikt hier. Ik moest het er maar mee doen dus.

[Flyduck]

Verwijderd schreef op 04 november 2002 @ 10:51:
Het is opgelost! Het bleek te liggen aan een fout in de ISA server LAT, de firewall verslikte zich vreemd genoeg erover als ik de adressen van het 200.1.7.x netwerk in de LAT van de ISA server op het 200.1.4.x zette (omdat hij beide als lokaal dient te beschouwen naar mijn mening en dus geen packet filters dient toe te passen op dit verkeer tussen de 2 netwerken). Ik heb deze 200.1.7.x range uit de LAT gehaald en toen werkte het ineens perfect en kon ik netjes alles bereiken!

In ieder geval bedankt voor alle hulp.

Mjah handig dat je in je probleemomschrijving helemaal nix vermeld hebt over ISA servers / firewalls. We moeten in principe maar raden dat je dat gebruikt en dat daar het probleem kan liggen?