Site-to-Site VPN - Geen rdp mogelijk

[Verwijderd]

Beste allemaal,

Na uren gestuntel, sta ik voor een raadsel.
Een klant van ons heeft een site-to-site vpn verbinding tussen bedrijf A en bedrijf B via een provider X. Ze hebben dus geen rechtstreekse verbinding met elkaar, bedrijf X koppelt ze als het ware.

Bij beide bedrijven staat een Cisco 836 router (ISDN).

Bij bedrijf B draait een terminal server waar iemand van bedrijf A op moet kunnen werken.

Nu het vreemde. Op de net opnieuw geinstalleerde WinXP Pro SP2 machine bij bedrijf A kan ik niet RDP'en naar de Terminal Server van bedrijf B. Als ik mijn laptop eraan hang, gaat het wel direct.

Als ik echter een VPN aanmaak (Windows PPTP VPN) op die bewuste WinXP Pro SP2 bak en dan RDP, dan gaat het wel.

Heeft iemand dit vaker gehad? Heeft het iets met MTU size te maken oid? Ik vind het een vreemd verhaal en ben er nog niet achter wat het zou kunnen zijn. Ik heb al geprobeerd de MTU waarden te wijzigen in het register (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Ndiswan\Parameters\Protocols\0
), maar tevergeefs.

<kleine opmerking nog> VNC'en naar de Terminal server gaat wel, maar krijg alleen zwart beeld te zien (terwijl dit op m'n laptop ook gewoon goed gaat)

[ Voor 6% gewijzigd door Verwijderd op 03-07-2007 19:43 ]

[ChaserBoZ_]

Kun je wel onderling pingen ?
En als dat lukt, probeer eens met pakketgrootte 1500 bytes ?

Edit; en de optie 'niet fragmenteren' uiteraard.

[ Voor 22% gewijzigd door ChaserBoZ_ op 03-07-2007 20:09 ]

[BrammeS]

ChaserBoZ_ schreef op dinsdag 03 juli 2007 @ 20:09:
Kun je wel onderling pingen ?
En als dat lukt, probeer eens met pakketgrootte 1500 bytes ?

Edit; en de optie 'niet fragmenteren' uiteraard.

9 van de 10 keer liggen dit soort dingen aan de routering. check de volgende zaken:

- hebben de systemen mischien een default route naar een internetrouter/proxy server ipv naar de vpn router. voeg dan een nieuwe default route(bv. route add 192.168.2.0 mask 255.255.255.0 192.168.1.254 -p) toe.
- check of je van bedrijf A naar B kan, maar check ook of je van bedrijf B weer terug kan naar A. soms komt data wel aan op de terminal server maar kan de weg niet terug vinden naar bedrijf A. dus default routes ook op de terminal server checken.

Het doen van een traceroute kan vaak handig zijn om te kijken waar iets fout gaat.

[ Voor 0% gewijzigd door BrammeS op 04-07-2007 07:51 . Reden: Eerst goed lezen en dan pas reageren, ik lees nu pas je laatste regel! ]

[StevenK]

Firewall op die sp2 bak staat wel uit?

[Flyduck]

Zou ook gewoon licentie technisch een probleem kunnen zijn.. kan je wel telnetten naar poort 3389 van de Terminal server vanaf die client?

[Verwijderd]

Onderling pingen lukt gewoon.

Met verschillende pakketgroottes had ik ook geprobeerd.
ping -l 1500 -f 192.168.10.251
1500 bytes lukt niet, verder naar beneden lukt het vanaf 1473 (en lager dus)

De systemen hebben voor zover ik kan zien geen default route naar een internetrouter/proxy server, maar gewoon naar de vpn router.
Vreemde is dat mijn laptop het wel doet, en die vaste PC niet.

Firewall uitzetten heb ik (uiteraard) ook al geprobeerd.

Licentietechnisch probleem en dan helemaal geen verbinding krijgen, dus amper het login scherm van de Terminal Server?
Ik heb dat nog niet eerder meegemaakt.
En ik kan gewoon telnetten naar port 3389.

Moet het denk toch in die MTU sizes gaan zoeken oid. Bij mijn laptop staan die misschien anders dan op die vaste PC.

[Flyduck]

Tsja dan moet je toch ff een sniffer erop zetten (ethereal) en pakketjes vergelijken met die van je laptop.
Lijkt wel op een PAT probleem.. heb je al ander ip adres geprobeerd? MTU zou idd ook kunnen, maar dan moet er wel een reden zijn dat die afwijkt.. werken jullie met VOIP?

[ChaserBoZ_]

Je kunt dit soort problemen inderdaad krijgen als je geen 1500 bytes kunt pingen, vraag je provider eens hoe dat netwerk/VPN is opgebouwd.

Als beide locaties het internet op gaan, en de provider hierover tunnelt, moeten ze de IP MTU vna die tunnel ophogen naar 1500.