VPN Tunnel hinter NAT

[Bytesplit]

Hallo und gute N8,

ist doch schon recht spät aber jetzt häng ich hier schon wieder das ganze Wochenende an der Kiste, nur weil ich dieses biestige VPN zum laufen bekommen möchte.

Ich habe folgendes vor:
VPN-Einwahlserver für Clients unter Windows 2000 und XP (geht nich anders ). System ist bist jetzt ein FreeBSD 5.3. Nun nehme ich aber auch eine Migration nach OBSD oder NetBSD in Kauf.

IPSec scheint aufgrund mangelnder NAT-Fähigkeit bzw. fehlender NAT-T Patches trotz wahrscheinlich bester Eignung (mit l2tp) von vornherein auszufallen.

PPTP benötigt mppe, was pppd unter FreeBSD nicht mitmacht. Wir dachten bereits an IPSec over PPTP, aber das wird sich sicher nicht routen lassen.

OpenVPN ist also das einzige was sich einigermaßen durch NAT bekommen lässt und auch unter FreeBSD zur Verschlüsselung zu bewegen ist. Leider muss ich die Software beim Client installieren und auf Serverseite mehrere Daemons an versch. Ports laufen lassen. Also gerade die Konfiguration von sowas ist da nicht das gelbe vom Ei.


Also besonders beim Thema NAT-T würde ich gerne ein paar genauere Fakten hören, falls einer in dem Gebiet bewandert ist. In OpenBSD-current scheint sich ja mit dem isakmp noch einiges in der Richtung zu tun. Einen Patch für NetBSDs KAME habe ich per Google auch schon erwähnt gelesen. Für FreeBSD (noch die erste Wahl da eben installiert) scheints noch mau auszusehen.


Geht sowas wirklich nur mit CISCO Gerätschaften?

 

[marty]

da gibt es noch Produkte anderer Hersteller

Was mich mal noch interessiert: hast du es mal hinbekommen, mit W2K zu einen der BSDs eine IPSec Verbindung aufzubauen (ohne NAT)? Wenn ja, hast du da ne brauchbare Howto?
Hab das schon mal aus Interesse mit OpenBSD probiert, aber nach ein paar Stunden entnervt aufgegeben.

Gruß ebenfalls aus Mainz

marty

 

[Bytesplit]

also bei mir lief das IPSec im Transportmode fürs L2TP (net/sl2tps). Konfig von racoon und setkey kann ich dir geben falls benötigt. Im Moment bin ich nich an der Kiste.

Die Konfig von IPSec ohne L2TP ist nach dem was ich bei M$ gesehen hab aber wirklich nicht ganz ohne. Registry verändern und so Kram, das begeistert mich jetzt nicht so wirklich.

 

[Hubert]

OpenVPN ist also das einzige was sich einigermaßen durch NAT bekommen lässt und auch unter FreeBSD zur Verschlüsselung zu bewegen ist. Leider muss ich die Software beim Client installieren und auf Serverseite mehrere Daemons an versch. Ports laufen lassen. Also gerade die Konfiguration von sowas ist da nicht das gelbe vom Ei.

Bei OpenVPN 2.0 braucht man nicht länger verschiedene Prozesse, die auf verschiedenen Ports lauschen.

 

[mikefeldmeier2]

VPN-Einwahlserver

Hallo und gute N8,

ist doch schon recht spät aber jetzt häng ich hier schon wieder das ganze Wochenende an der Kiste, nur weil ich dieses biestige VPN zum laufen bekommen möchte.

Ich habe folgendes vor:
VPN-Einwahlserver für Clients unter Windows 2000 und XP (geht nich anders ). System ist bist jetzt ein FreeBSD 5.3. Nun nehme ich aber auch eine Migration nach OBSD oder NetBSD in Kauf.



Also besonders beim Thema NAT-T würde ich gerne ein paar genauere Fakten hören, falls einer in dem Gebiet bewandert ist. In OpenBSD-current scheint sich ja mit dem isakmp noch einiges in der Richtung zu tun. Einen Patch für NetBSDs KAME habe ich per Google auch schon erwähnt gelesen. Für FreeBSD (noch die erste Wahl da eben installiert) scheints noch mau auszusehen.


Geht sowas wirklich nur mit CISCO Gerätschaften?

BSD 5.3: Der VPN Port existiert. Bei Bedarf umschreiben.

PPTP ist ein Microsoft-Protokoll (wuerg).

Wenn eh nur Windows Clients in Frage kommen: Einfach auch
einen virtuellen Windows-VPN-Einwahlserver aufsetzen. Da gleichen
sich die Bugs Server/Clientseitig aus.

Mit vmware geht das ganz gut.

Warum nicht tightvnc via ssh oder X-Server via ssh ?

MfG

MFC

 

[Bytesplit]

BSD 5.3: Der VPN Port existiert. Bei Bedarf umschreiben.

net/mpd scheint einen recht guten Job zu machen. Nutzt glaub ich kernel-ppp (wie auch der hervorragende sl2tps), der ja inzwischen MS-CHAP u. MPPE unterstützt.

PPTP ist ein Microsoft-Protokoll (wuerg).

Ich würde auch lieber drauf verzichten, aber eine grosse Auswahl haben wir da im Moment nicht.

Wenn eh nur Windows Clients in Frage kommen: Einfach auch
einen virtuellen Windows-VPN-Einwahlserver aufsetzen. Da gleichen
sich die Bugs Server/Clientseitig aus.

dafür müsste die Hardware der Firewall schon einiges mehr hergeben. Mit Vmware unter FreeBSD hatte ich aber auch bei mir schon nur Probs.

Warum nicht tightvnc via ssh oder X-Server via ssh ?

Ich geh ja per ganz normalen SSH drauf. Aber es sollen Endanwender, von zu Hause aus auf den Windoof-Terminalserver gelangen. Und wenn das Gateway das VPN macht kann ich auch auf versch. Terminalserver schalten (je nach Nutzeranmeldung sollen die unterschiedl. IPs bekommen)

 

[mikefeldmeier2]

vmware

net/mpd scheint einen recht guten Job zu machen. Nutzt glaub ich kernel-ppp (wie auch der hervorragende sl2tps), der ja inzwischen MS-CHAP u. MPPE unterstützt.


Ich würde auch lieber drauf verzichten, aber eine grosse Auswahl haben wir da im Moment nicht.


dafür müsste die Hardware der Firewall schon einiges mehr hergeben. Mit Vmware unter FreeBSD hatte ich aber auch bei mir schon nur Probs.


Ich geh ja per ganz normalen SSH drauf. Aber es sollen Endanwender, von zu Hause aus auf den Windoof-Terminalserver gelangen. Und wenn das Gateway das VPN macht kann ich auch auf versch. Terminalserver schalten (je nach Nutzeranmeldung sollen die unterschiedl. IPs bekommen)

Hi !

Heutige Sperrmüllrechner sollten genug hergeben, um das gewünschte
zu erreichen. Nimm Doch coLinux statt vmware und BSD.

MfG

MFC

 

[Bytesplit]

der Vollständigkeit halber...

inzwischen habe ich den VPN-Server auf mpd laufen. Nach einiger Plackerei mit dessen Configs kann ich jetzt von Endanwender-Systemen wie OSX und Windoof bequem aufs LAN zugreifen.

An der MTU muss ich fürs Windoof noch drehen, die Einstellungen von PF hab ich auch noch nicht ganz, aber grundsätzlich geht es.

Für IPSEC NAT-Traversal gibt es ja was im aktuellen OpenBSD (werd ich mir noch reinziehen) sowie einiges im 2.6er Linux-Kernel in Kombination mit IPSec-Tools bzw. OpenSWAN. Wer also nicht direkt an FreeBSD gebunden ist...

Das KAME Project sieht, soviel ich herausbekommen konnte, NAT-T noch nicht als so wichtig an, weshalb dort die Arbeit noch nicht weit ist (ach, wenn ich nur ein bischen mehr über C wüsste). Die RFCs scheinen aber inzwischen durch zu sein, und Patentansprüche seitens M$ u. Co KG scheint es wohl auch nicht mehr zu geben.

Dennoch, IPSEC würde, gerade mit den hierzulande ja nachgeworfenen NAT-Routern noch ein wenig besser aussehen.

 

[mikefeldmeier2]

IPSEC-mpd

der Vollständigkeit halber...

inzwischen habe ich den VPN-Server auf mpd laufen. Nach einiger Plackerei mit dessen Configs kann ich jetzt von Endanwender-Systemen wie OSX und Windoof bequem aufs LAN zugreifen.

...

Das KAME Project sieht, soviel ich herausbekommen konnte, NAT-T noch nicht als so wichtig an, weshalb dort die Arbeit noch nicht weit ist (ach, wenn ich nur ein bischen mehr über C wüsste). Die RFCs scheinen aber inzwischen durch zu sein, und Patentansprüche seitens M$ u. Co KG scheint es wohl auch nicht mehr zu geben.

Dennoch, IPSEC würde, gerade mit den hierzulande ja nachgeworfenen NAT-Routern noch ein wenig besser aussehen.

Hi !
endlich mal ein vernünftiger im Forum der selbstverliebten. Habe
mir auch den mpd auf meine ports-distfiles gezogen. Bin jedenfalls
begeistert ! Werde in Kürze mal meine cfg-files posten.

MfG

MFC

 

[Bytesplit]

Zu IPSec... vom IPSec Tools-Team hab ich jetzt nen FreeBSD build bekommen, mal sehen wie der zu kompilieren ist. NAT-T ist dort wohl bis jetzt im Rahmen von Tunneling implementiert, für Transport reichts noch nicht. Die Zeit bringt mehr...