[VPN] inbound vpn falen sinds nieuwe router.

[kvdveer]

Wij hebben een bedrijfsnetwerk draaien dat via een router aan het internet verbonden is/was. Vannacht frituurde de router zichzelf ('t was een oude Pentium 200) en hebben we moeten besluiten om het ding te vervangen. Om toekomstige problemen te voorkomen hebben we gekozen voor een prefab wlan + wireless router van linksys. (type wrt54g-eu)

Onze oude router (koosnaam:pluto) had naast het routen nog een taakje: hij was ook VPN-server. (pptpd + pppd).
even een schets van de oude opzet:
[interne machines] --- [pluto]-- &&internet&& -- [werknemer]

In de nieuwe situatie willen we onze general-service-server (koosnaam:jupiter) inzetten als VPN-server. Intern gaat dit prima, maar helaas willen onze werknemers thuis telewerken.
Zodra het via de router loopt, mislukt de verbinding. Windows is niet zo informatief, linux gelukkig wel. Onder aan dit bericht vind je een linkje naar tcpdump van een intern gelukte verbinding en een extern mislukte verbinding.

Ik heb als alternatief voor pptp nog l2tp overwogen, maar om de een of andere reden lukt dat helemaal niet (tcpdump meldt geen inkomende pakketen, windows zegt dat het eea niet gelukt is).

---

Bij het bestuderen van de traces valt een belangrijk ding op: er komen geen gre-pakketjes binnen op de falende verbinding. Dit is hoogstwaarschijnlijk de oorzaak van alle problemen.
In de router heb ik echter de optie "pptp passthrough" aan staan. Als ik deze uitzet is het effect overigens hetzelfde.

Heeft er iemand een idee wat ik aan dit probleem kan doen?

---

specs:
clientmachine: windows2000sp1. (moet overigens gaan werken op w98se, linux en winxp)
server: debian sarge, kernel 2.4.18 (out of the box), PoPToP v1.1.4-b3, pppd version 2.4.2b3. Services: bind, ssh, rsync, samba, http, postgre, mysql.
Verbinding: pppoe van luna, 10mbit static ip. Client is chello. Vanuit de router worden alle poorten doorgestuurd naar jupiter.

---

Zoals beloofd de tcpdumps van Gelukte verbinding (intern) en Mislukte verbinding (extern)

[Predator]

PNS -> NOS

[grhmpf]

Het probleem zit hem in het feit dat je waarschijnlijk achter een NAT router zit. VPN (pptp etc) kan absoluut niet tegen NAT omdat het source ip voor NAT natuurlijk verschilt van het IP na NAT. Dus klopt de checksum op de VPN pakketten niet meer dus krijg je niets. Mocht je met public ip's werken met de VPN in een DMZ of iets dergelijks dan is het natuurlijk een ander verhaal.

Ah ik zie in je log dat je inderdaad naar een private ip forward, dat moet haast wel het probleem zijn.

[ Voor 17% gewijzigd door grhmpf op 13-11-2003 21:20 ]

[kvdveer]

De router heeft een DMZ mogelijkheid. Hoe zou ik het dan aan moeten pakken?
Ik heb ons ipadres toegekend aan de interne machine, maar dat werkt niet. De adressen worden toch ge-nat.

Een ander, gerelateerde vraag: Wie is er verantwoordelijk voor het verzenden van een pakketje met het juiste return-ip? Is dat pptpd of pppd?

[grhmpf]

DMZ heb je alleen wat aan als je nog een apart subnet hebt, dwz een range ips voor de DMZ en een voor de router/firewall. Dat heb je denk ik niet dus dat houdt snel op. De server zal z'n interne ip nu sturen (technisch pptpd, pptpd draait op poort 1723 en start pppd op, pppd heeft geen "directe" connectie met de client).

Om de een of andere reden is mijn verbinding brak, maar als je op google zoekt op vpn en nat of poptop en nat dan moet je een eind komen. Er is geloof ik ook een linux howto waarin vpn in combinatie met NAT beschreven is.

Volgens mij zal het een en ander niet zo gemakkelijk aan de praat te krijgen zijn met een private ip, zo niet onmogelijk. Het enige wat je dan kan doen is de router vervangen door een linux/bsd of whatever oplossing waarbij de vpn op de firewall zelf zit.

[ Voor 9% gewijzigd door grhmpf op 13-11-2003 23:49 ]

[Redje]

In principe is pptp en nat mogelijk, alleen moet je dan poortje 1723 tcp en protocol GRE (type 47) forwarden naar de vpn server.
Dit werkt prima met Windows 2000 pptp vpn, pptpd zou dan ook wel moeten werken.

/edit:
Ook Freeswan (=ipsec, proto 50/51, en udp 500) werkt goed met forwarding.

[ Voor 23% gewijzigd door Redje op 14-11-2003 00:01 ]