[RRAS] Site-to-site-VPN

[Ulster Seedling]

Hallo tweakers,

Sinds gisteren probeer ik een site-to-site-VPN op te zetten met RRAS op twee 2K8r2-bakken. Inmiddels ben ik zover dat de verbinding werkt, maar het lukt me nog niet om het verkeer van de ene site naar de andere site te sturen.

Set-up: de set-up is op beide sites hetzelfde: de server hangt aan een router die weer aan een modem hangt. De routers functioneren als DHCP-server en delen IP-adressen uit in de range subnet.21-subnet.100. Beide servers hebben een statisch IP-adres, namelijk subnet.11, en zijn ingesteld als DMZ.

Configuratie: de servers zijn geconfigureerd met de wizard om een site-to-site-verbinding te maken. Dit gaat met een demand-dial-interface en een PPTP-VPN-verbinding. Zoals gezegd werkt de VPN-verbinding.

Probleem: het lukt me niet om het verkeer bedoeld voor de andere site, over de VPN-verbinding door te sturen. Op beide locaties heb ik een static route (home, office 1) toegevoegd en is deze te zien in de IP routing table (home, office 1), aangezien deze route niet vanzelf verscheen. Ik vermoed dat deze laatste stap niet helemaal klopt, bijvoorbeeld omdat er in de routing table "non demand-dial" staat, wat mij nogal onlogisch lijkt.

Home:

• Subnet: 10.0.1.0/24
• Router: 10.0.1.1
• Server: 10.0.1.11 (DMZ)
• DHCP: 10.0.1.21-10.0.1.100
• RRAS DHCP: 10.0.1.101-10.0.1.150

Office 1:

• Subnet: 10.0.2.0/24
• Router: 10.0.2.1
• Server: 10.0.2.11 (DMZ)
• DHCP: 10.0.2.21-10.0.2.100
• RRAS DHCP: 10.0.2.101-10.0.2.150

Hopelijk heeft iemand idee hoe ik deze route toch werkend krijg!

Groet, Jonathan.

[Ulster Seedling]

Inmiddels ben ik twee dagen verder, maar helaas heb ik het verlossende antwoord nog niet mogen lezen. Wil ik iets dat onmogelijk is? Hopelijk leest iemand dit die er wat verstand van heeft, de bedoeling is namelijk dat het thuisnetwerk zo snel mogelijk draaiende is ;-)

Wat ik in de TS niet vermeldde maar wat misschien wel van belang is, is het doel van deze verbinding. Ten eerste moeten de twee servers onderling communiceren (AD DC, DFS, etc …). Tevens moeten de clients via de op hun site, kunnen verbinden met de server op de andere site. Hiervoor ga ik een script schrijven dat wordt gedraaid tijdens het inloggen, en dat een static route op de client toevoegt die de 'lokale' server instelt als gateway voor het verkeer naar de 'externe' server.

[alt-92]

Ik zou zoiets in dat geval zelf niet met point to point tunnels op je servers gaan doen maar lekker een site2site ipsec VPN tussen daarvoor geschikte routers opzetten.
Maar dat ben ik.

[ Voor 4% gewijzigd door alt-92 op 27-02-2011 15:03 ]

[Paul]

Idem hier

Maar goed, RRAS. Ik zou zeggen, ga basic troubleshooten, steeds een stapje verder

- Wordt de VPN opgebouwd?
- Kun je van server 1 naar server 2 pingen?
- Heeft je client een static route naar het remote subnet met de lokale server als gateway?
- Kun je van je client naar de lokale server pingen?
- Kun je van je client naar de remote server pingen?
- Al deze stappen ook andersom, dus vanuit de andere locatie
- en ten slotte, kan de locale client naar de remote client?

[Ulster Seedling]

alt-92 schreef op zondag 27 februari 2011 @ 14:57:
Ik zou zoiets in dat geval zelf niet met point to point tunnels op je servers gaan doen maar lekker een site2site ipsec VPN tussen daarvoor geschikte routers opzetten.
Maar dat ben ik.

Hierin moet ik je natuurlijk gelijk geven, deze oplossing is absoluut niet elegant. Het is echter zo dat ik hier thuis een aantal maanden geleden het hele netwerk al vervangen heb en dus liever niet allerlei apparatuur weer weg kan gooien. Daarnaast betreft het een klein netwerk, het gaat me erom dat de verbinding straks redelijk werkt, een hoge snelheid snelheid of 100% betrouwbaarheid is geen eis.

---

Paul Nieuwkamp schreef op zondag 27 februari 2011 @ 15:12:
Maar goed, RRAS. Ik zou zeggen, ga basic troubleshooten, steeds een stapje verder

- Wordt de VPN opgebouwd?
- Kun je van server 1 naar server 2 pingen?
- Heeft je client een static route naar het remote subnet met de lokale server als gateway?
- Kun je van je client naar de lokale server pingen?
- Kun je van je client naar de remote server pingen?
- Al deze stappen ook andersom, dus vanuit de andere locatie
- en ten slotte, kan de locale client naar de remote client?

De VPN-verbinding wordt goed opgebouwd. Als ik op één van de servers verbinding laat maken duurt dit een paar seconden. Daarna is op beide servers te zien dat ze met elkaar verbonden zijn. De network interface staat dan op "connected" en WAN miniport (PPTP) op "active".

Daarna beginnen de problemen echter: het lukt mij niet om data over de VPN-verbinding te krijgen. Ik kan pingen wat ik wil (naar adressen uit het externe subnet, naar het adres dat aan de VPN is toegewezen, aan ieder adres wat je kunt bedenken) maar ik krijg niets terug.

Mijn vermoeden is dat dit komt doordat er geen route naar het externe subnet in de IP routing table te zien is. Zonder zo'n route kan het natuurlijk nooit lukken om verkeer ernaar te versturen. Ik heb dus geprobeerd een static route toe te voegen, zoals beschreven in de TS, maar dat had geen effect.

Het (eerste) probleem is dus: er gaat geen verkeer over de VPN-verbinding. Iemand idee waar dit aan ligt en hoe het op te lossen valt?

[nielsl]

als 2 computers elkaar niet kunnen pingen, dan zou ik zeggen dat er iets van een firewall staat te pesten oid. Desalniettemin: Heb je al eens in de route tabel van één van je servers gekeken? Als je niet van server naar server kunt pingen dan wordt het óf ergens geblokked door een firewall, óf de servers zijn ingesteld om niet op pings te reageren lijkt mij....

[Ulster Seedling]

nielsl schreef op zondag 27 februari 2011 @ 19:54:
als 2 computers elkaar niet kunnen pingen, dan zou ik zeggen dat er iets van een firewall staat te pesten oid. Desalniettemin: Heb je al eens in de route tabel van één van je servers gekeken? Als je niet van server naar server kunt pingen dan wordt het óf ergens geblokked door een firewall, óf de servers zijn ingesteld om niet op pings te reageren lijkt mij....

Zoals gezegd komt er niet automatisch een route bij in de route table van de servers, en als ik handmatig een static route toevoeg werkt het ook niet.

Verder staan beide servers als DMZ ingesteld op de router, de enige firewall/blokkade is dus Windows Firewall. Als test heb ik deze op beide servers uitgeschakeld, maar ook dan lukt het pingen niet. De servers reageren wel op pings van clients uit hetzelfde subnet, dus het lijkt me dat ze dan toch ook op andere pings reageren?

Ik vermoed nog steeds dat het aan de route ligt die niet automatisch wordt aangemaakt. Iemand idee?

[mookie]

Bij RRAS (en ook bij ISA) gaat het erom dat de gebruikersnaam en de tunnel dezelfde naam hebben.

Dus als je tunnel (je adapter) VPNTUNNEL heet en je gebruiker VPNGEBRUIKER heet dan gaat het niet werken.
Dan denkt de VPN server dat er een normale VPN sessie opgebouwt wordt.
Het resultaat is makkelijk te controleren.
- je kunt na verbinden van de tunnel wel de VPN server pingen, maar geen hosts achter de VPN server
- onder RRAS (Local) -> remote acces clients zie je iets als "remote access clients (1)" wat beteken dat er 1 verbinding is, maar dat is dus geen tunnel. Bij tunnels staat er geen getal achter de haakjes
- onder RRAS (Local) -> Ports zie je wel je dat er 1 of meerdere ports active zijn (1 in jouw geval) maar dus geen 1 bij de remote access clients, dat zou fout zijn.

Als je er 1 onder de remote access clients ziet is je tunnelnaam anders dan de gebruikersnaam die je ervoor gebruikt.
Dit aanpassen en dan is het opgelost.

Verders moet je bij de wizard aangeven wat je "internet" kaart is.
Als je dat naderhand omwisselt geeft dan problemen. Oplossing is "RRAS (Local)" -> Disable routing and remote access en daar de wizard opnieuw doorlopen.
Maar dit lijkt me bij jou niet het geval.

Je tunnel wil je als volgt instellen:
Onder properties van je tunnel, tabblad options kies je "persistant connection", redial attempts 99 en average redial zet ik altijd op 10 minuten, anders is die 99 zo om bij een storing op de lijn maar je bent vrij om een andere waarde te kiezen.

De route zijn niet te zien zijn in je route table totdat de tunnel is opgebouwd.
Daarna komt hij er automatisch in.
Als hij er niet in komt dan is dat omdat:
- je geen tunnel hebt omdat de tunnelnaam/adapternaam en gebruikersnaam verschilt of je RRAS config vernachtelt is.
- je het verkeerde subnet mask gebruikt. (je schrijft /24 maar controleer even of je ook echt 255.255.255.0 hebt ingevoerd, voor een 10.x.x.x adres is dat standaard namelijk een /8 oftewel 255.0.0.0)

Teneinde ben ik het met alt-92 eens dat een L2TP tunnel met IPSEC encryptie vele malen veiliger is, echter ik gebruikt ook altijd PPTP omdat die ten minste aangeven of de tunnel actief is of niet.
Bij een L2TP moet je maar zien of het aankomt, net als wanneer je de verkeerde key in een WEP of TKIP draadloos netwerk verkeerd invoert.
PPTP zie je altijd of hij connected is of niet, bij L2TP/IPSEC zie je niets.

Je zegt zelf: De network interface staat dan op "connected" en WAN miniport (PPTP) op "active".
Maar dat is altijd... ook als het geen tunnel verbinding is maar een losse, laten we het noemen "client" verbinding is.
Controleer of je geen verbindingen ziet onder RRAS (Local) -> remote acces clients, dat zou fout zijn.

Dus lang verhaal kort maken:
- tunnel/adapternaam hetzelfde als gebruikernaam
- route moet vanzelf toegevoegd worden als de tunnel actief is, te controleren met "route print"
- geen route en geen "remote access clients" dan is je config verneukt, gewoon "disable routing en remote access" en daarna opnieuw instellen.

Ik gebruik het op 9 locaties met RRAS en PPTP tunnels en het werkt geweldig.

[alt-92]

mookie schreef op maandag 28 februari 2011 @ 04:01:

Teneinde ben ik het met alt-92 eens dat een L2TP tunnel met IPSEC encryptie vele malen veiliger is, echter ik gebruikt ook altijd PPTP omdat die ten minste aangeven of de tunnel actief is of niet.
Bij een L2TP moet je maar zien of het aankomt, net als wanneer je de verkeerde key in een WEP of TKIP draadloos netwerk verkeerd invoert.

Meh.. dan kun je dat in Advanced Firewall wel herkennen omdat er een SA is

Maar een andere reden om van PPTP af te zien is omdat het een verouderd, kwetsbaar protocol is wat bovendien op de nominatie staat deprecated te worden

[Razwer]

alt-92 schreef op maandag 28 februari 2011 @ 08:30:
[...]

Meh.. dan kun je dat in Advanced Firewall wel herkennen omdat er een SA is

Maar een andere reden om van PPTP af te zien is omdat het een verouderd, kwetsbaar protocol is wat bovendien op de nominatie staat deprecated te worden

en nog eens rete onstabiel...

mookie schreef op maandag 28 februari 2011 @ 04:01:
Bij een L2TP moet je maar zien of het aankomt, net als wanneer je de verkeerde key in een WEP of TKIP draadloos netwerk verkeerd invoert.
PPTP zie je altijd of hij connected is of niet, bij L2TP/IPSEC zie je niets.

dat is natuurlijk een non argument.
Je kan prima zien of je phase1 en phase2 doorlopen.

Toevallig had ik laatst issues met een ipsec tunnel tussen 2 ASA's wat ik met Alt92 besprak omdat ik dacht dat ik gek was (ben ik ook wel een beetje maar dat is een ander verhaal) waarbij ik idd niets zag gebeuren. Daar bleek een router die er tussen zat geen verkeer door te laten van ip adressen die niet op zn ACL stonden. Dan zie je idd niets. Anderzijds komen er altijd berichten over phase1 en phase2 en kun je daarvanuit troubleshooten....

[ Voor 3% gewijzigd door Razwer op 28-02-2011 09:34 ]

[alt-92]

offtopic:
Toch die 1811?

[Razwer]

offtopic, 1811 op site B, niet site A wat ik eerst dacht

[ Voor 13% gewijzigd door Razwer op 28-02-2011 14:39 ]

[Ulster Seedling]

@mookie: Thanks voor je uitleg, je hebt er duidelijk ervaring mee! Helaas heb ik de verbinding nog steeds niet werkend.

Als eerste heb ik de zaak weggegooid (disabled) en ben ik na een herstart opnieuw begonnen. Hierbij koos ik voor de optie "Secure connection between two private networks" als configuratieoptie, dat lijkt me toch goed? Ik kreeg in de wizard echter geen optie om een netwerkkaart te kiezen, waar jij het wel over hebt. Zit ik misschien iets verkeerds te doen tijdens deze eerste stap?

Op beide servers heb ik als gebruikersnaam (zowel inkomend als uitgaand) en naam van de Network Interface "VPN_Home_Office1" gebruikt. Dat is steeds letterlijk gekopieerd uit mijn password manager, hierin kunnen dus geen fouten zijn ontstaan. Het subnet is verder goed ingevuld in de wizard, ik kan het naderhand echter niet meer terugvinden ter controle.

Er zouden dus geen problemen mogen ontstaan, maar toch zijn deze er …

Wat ik verder vreemd vind is dat ik "RRAS > Remote Access Clients" (waar jij meermaals naar verwijst) niet kan vinden. Ik heb enkel Network Interfaces (met daaronder de VPN), Ports (met heel veel meuk en één active poort), Remote Access Logging & Policies, IPv6 (oninteressant) en IPv4 met daaronder General (weer de VPN eronder), Static Routes en NAT (beide leeg).

Wat verder nog opvalt is dat de verbinding bijzonder instabiel is, terwijl er nog niet eens verkeer over verstuurd wordt (kan worden). Soms lukt het verbinden niet en moet je handmatig annuleren en opnieuw verbinding maken voordat het wel werkt. Andere keren valt de verbinding na een aantal minuten alweer weg en moet je wachten op een nieuwe verbinding, die niet altijd slaagt. Hoort dit, of duidt dit op andere problemen?

Hopelijk heb jij of heeft iemand anders nog even tijd en zin om me op weg te helpen. Zelf kom ik er, zelfs samen met Google's hulp, niet meer uit en ik hoop toch dat ik deze koppeling binnenkort werkend krijg. Nogmaals bedankt iedereen!

[mookie]

@rawzer
heb de indruk dat je alleen maar cisco gebruikt.
PPTP tunnels met cisco is (heb ik gehoord) niet echt een droom, ook niet tussen een 2000/2003/2008 server en een cisco (uit eigen ervaring).
Maar tussen windows server en windows server is het zeker stabiel.
Ik zie er net 1 tussen zitten met een uptime van 51 dagen (wordt ook bijna niets overheen gestuurd), maar als ze wegvallen zijn ze ook zo weer terug.
Microsoft PPTP is nogal anders dan echt/gewoon PPTP.
Microsoft heeft zich niet echt aan de standaard gehouden... op sommige punten is dat beter en op sommige punten slechter.

En in een ASA kun je inderdaad snel zien of je door de PKI fases heen bent gekomen.
Met windows RRAS is dat veel moeilijker, dat zie je nergens terug in de management console, dan moet je met netsh gaan goochelen, iets wat voor de beginnende gebruiker niet echt is weggelicht.

De TS gebruikt echter windows RRAS en geen Cisco ASA.

@jhogervorst
Als je de middelste optie "Virtual Private Network (VPN access and NAT" kiest krijg je wel de keuze wat je externe kaart is, hoewel dat eigenlijk alleen maar is om aan te geven in welke richting de NAT moet lopen en of je er een basic firewall op wilt of niet.
Met NAT kun je de server ook meteen je internet verbinding laten delen.
Je zult dan ook "RRAS > Remote Access Clients" zien wat dan kun je ineens ook gewone normale client sessies opbouwen ipv alleen site-to-site tunnels.

Overigens is het wel zo dat niet alle routers (lees, thuis routertjes van < €50 (linksys, thompson)) niet altijd lekker omgaan met het forwarden van MS PPTP verkeer.
Het beste is om je modem in bridged mode te zetten zodat het publieke IP adres meteen op de server terecht komt.
Vaak als je dat niet doet en enkel poort 1723 forward werkt het moeizaam en instabiel (wat overigens ook voor L2TP geldt)

Aan de hand van je IP adres lijst neem ik aan dat je een router hebt die al het externe verkeer forward naar 10.0.1.11.
Als je op je gewone windows client enkel een default gateway (10.0.1.1) hebt ingesteld en je server kan de VPN tunnel maken, dan zul je op je client juist een extra route moeten toevoegen en niet op de server.
Op je client in een cmd prompt type je dan b.v. "route -p add 10.0.2.0 NETMASK 255.255.255.0 10.0.1.11"
Dan weet jouw computer dat verkeer voor 10.0.2.x naar je VPN server moet en niet naar je gewone router.
En als jij dan een client pinged die op het 2de netwerk zit, dan zul je op die PC ook een route moeten aanmaken naar de VPN server aldaar, anders gaan je pakketjes van 10.0.1.x wel naar 10.0.2.x maar die client aldaar zal het weer terugsturen naar zijn default gateway (10.0.2.1) en die dropped de pakketjes omdat hij niet weet wat hij ermee moet.

Dus het beste is om je server meteen aan die internet lijn te hangen door de modem in bridged mode te zetten.
Wil je dat niet dan is een andere (makkelijkere dan je huidige voorstel) mogelijkheid om 4 subnets te pakken.
Dan krijg je dit:

home client 10.0.2.150 -- 10.0.2.11 VPN server 10.0.1.11 -- modem 10.0.1.1 --- Home internet --
office internet -- modem 10.0.3.1 -- 10.0.3.11 VPN server 10.0.4.11 --- office client 10.0.4.150

Je gebruikt dan je VPN server als default gateway voor alle clients en dan kun je zonder moeite op alle clients gewoon internetten en over de VPN tunnel gaan zonder losse routes aan te hoeven maken.

Tevens kun je op je VPN server nog de DNS server installeren met gewoon de default settings.
Dan heb je ook je eigen caching DNS server... deed ik destijds toen ik nog bij @home zat en hun DNS servers lagen er (weer eens) uit.

[Razwer]

mookie schreef op woensdag 02 maart 2011 @ 04:04:
@rawzer
heb de indruk dat je alleen maar cisco gebruikt.

verkeerde indruk.

PPTP moet je gewoon niet gebruiken. punt.

[Ulster Seedling]

@mookie: Dankzij je post ben ik een stapje verder. Inmiddels kunnen clients (die de server als gateway hebben ingesteld) pingen naar het andere subnet, perfect dus! Het enige wat nog niet werkt, en absoluut wél moet werken, is dat de servers zelf niet kunnen verbinden met het andere subnet.

Hierbij de routing tables van home en office1. Weet jij, of iemand anders, misschien nog hoe ik dit laatste probleem kan tackelen?

Nogmaals vriendelijk bedankt! Het probleem is nu eindelijk bijna opgelost.

[Ulster Seedling]

Oké, godzijdank is alles inmiddels werkend! De oplossing was een static route in beide servers, iets wat publiek bekend is maar waar Microsoft geen oplossing voor heeft. Fijn, denk ik dan bij mezelf …

Nou, iedereen nogmaals heel erg bedankt voor de hulp, ik kan nu eindelijk door met het opzetten van het netwerk!

[Razwer]

microsoft geen oplossing voor heeft? route.exe is van microsoft.
op cisco apparatuur moet je ook zelf je routes maken en zelfs nog je crypto maps instellen.