Hallo!
Ich habe vor kurzem einen Rootserver bekommen, mit dem ich über IPSec reden will. In meinen bisherigen lokalen Experimenten habe ich manuelles setkey und OpenSwan erfolgreich verwendet.
Das Problem: Ich bin in einem privaten Netz (Bürgernetz), das über einen NAT-Router (auf dem ich keinen Account habe, geschweige denn root) ans Internet angeschlossen ist. Die Router haben DSL, d. h. ihre äußeren IP-Addressen können sich gelegentlich ändern.
Ich kann also in den SAD- und SPD-Regeln keine IP der Gegenstelle (meines Rechners) eintragen, die ist ja von außen nicht sichtbar.
Kann man in dieser Situation trotzdem einen IPSec-Tunnel aufbauen? Geht das evtl. mit dynamisch aufgebauten Tunneln und X.509-Zertifikaten (wie OpenSwan)? Hat das schonmal jemand gemacht und kann mir ein paar URLs oder Tipps geben?
Danke schon mal und schönes Wochenende!
Martin
am Fri, dem 25.06.2004, um 15:08:45 +0200 mailte Martin Pitt folgendes:
Hallo!
Ich habe vor kurzem einen Rootserver bekommen, mit dem ich über IPSec reden will. In meinen bisherigen lokalen Experimenten habe ich
Du willst remote eine einzelne Maschine administrieren? Wozu dann IPSec? SSH tut doch auch für sowas.
Kann man in dieser Situation trotzdem einen IPSec-Tunnel aufbauen?
NAT und IPSec ist an sich ein Widerspruch. Google man nach 'NAT traversal'.
Wenn ich Dich richtig verstehe, brauchst Du es nicht, und wirst es ohne Konfigurationsrechte auf dem Router auch nicht hinbekommen.
Andreas
Hallo Torsten,
On Fri, Jun 25, 2004 at 16:34:57 +0200, Torsten Werner wrote:
NAT und IPSec ist an sich ein Widerspruch. Google man nach 'NAT traversal'.
Naja, an sich geht das schon. Im Prinzip baut man erst einen UDP-Tunnel auf, aber vielleicht kann Christian Perle was vern?nftiges dazu sagen?
Es gibt ein IETF-Draft zu diesem Thema, der das Tunneln kompletter IPSec-Pakete in UDP Port 4500 Paketen verschlaegt. So kann der IP-Header des aeusseren Pakets (UDP) durch ein NAT-Gateway umgeschrieben werden, ohne dass der IP-Header des inneren Pakets (IPSec) angefasst wird.
bye, Chris
Hallo Andreas!
Am 2004-06-25 15:21 +0200 schrieb Andreas Kretschmer:
Du willst remote eine einzelne Maschine administrieren? Wozu dann IPSec? SSH tut doch auch für sowas.
Zur Administration taugt es auf jeden Fall, aber ich will ja die Kiste nicht _nur_ administrieren (okay, das macht Spaß, aber er soll ja auch zu was nütze sein). Insbesondere habe ich zwei Gründe für IPSec:
- NFS (okay, es gibt auch Coda usw., aber da müsste ich mich erst wieder reinarbeiten) - im Bürgernetz gibt es einen Zwangs-Mailproxy. Da ich aber meinen Server als Smarthost nehmen will, muss ich mich an dem Proxy irgendwie vorbeitunneln und IPSec würde das gleich mit erschlagen. - Mein Mitbewohner benutzt irgendein für ihn wichtiges Win$-Programm, was zwar ftp kann, aber noch nie was von ssh/sftp gehört hat. Und ich weigere mich einfach, telnet oder nichtanonymes FTP auf der Kiste zuzulassen.
Zusammenfassend ist IPSec einfach eine "einmal gemacht und dann Ruhe bei jeder Anwendung"-Sache und ich habe in Nicht-NAT-Netzen auch schon einige Erfahrung damit. Wäre halt schön, wenn das geht.
NAT und IPSec ist an sich ein Widerspruch. Google man nach 'NAT traversal'.
Eben, ich habe ja schon diverse Howtos gelesen, aber bisher nichts gefunden. Deshalb dachte ich, ich frage mal.
Wenn ich Dich richtig verstehe, brauchst Du es nicht, und wirst es ohne Konfigurationsrechte auf dem Router auch nicht hinbekommen.
Hmm, dann werd ich wohl ein bisschen probieren müssen. Im Prinzip müsste es doch ausreichen, den Peer nicht anhand der IP, sondern anhand eines anderen Merkmals (ein Passwort oder ein Zertifikat) zu erkennen, oder?
Danke und schönes Wochenende!
Martin
am Fri, dem 25.06.2004, um 18:43:51 +0200 mailte Martin Pitt folgendes:
Hmm, dann werd ich wohl ein bisschen probieren müssen. Im Prinzip müsste es doch ausreichen, den Peer nicht anhand der IP, sondern anhand eines anderen Merkmals (ein Passwort oder ein Zertifikat) zu erkennen, oder?
Das ist nicht wirklich das Problem. Das Problem ist eher, daß IPSec, wenn man es mit AH (Authentication Header, Protokoll 51) betreibt, die Authentizität der Header geprüft wird. Ein NAT macht diese aber kaputt bzw. manipuliert diese. Damit wird das per se als ungültig angesehen, bis zu einer Prüfung der Authentizität kommt es gar nicht erst. Du mußt also auf alle Fälle _ohne_ AH arbeiten. Ich betreibe einige FreeSwan-Strecken, allerdings noch die 1.9x - Version. Dort nutze ich AH. Die neueren FreeSwan/OpenSwan sind IMHO per default ohne AH, was aber noch nicht heißt, das es hinter NAT funktioniert.
Wenn Du es wirklich hinter NAT betreiben willst, solltest Du Dir Alternativen wie tinc, OpenVPN oder so ansehen, weiß allerdings jetzt nicht aus dem Steggreif, welche NAT-fest sind.
Du könntest Dich auch mal auf der Homepage von Spenneberg umschauen.
Andreas
Andreas Kretschmer wrote:
Wenn Du es wirklich hinter NAT betreiben willst, solltest Du Dir Alternativen wie tinc, OpenVPN oder so ansehen, weiß allerdings jetzt nicht aus dem Steggreif, welche NAT-fest sind.
Von http://openvpn.sourceforge.net/: "As a user-space VPN daemon, OpenVPN is compatible with with SSL/TLS, RSA Certificates and X509 PKI, NAT, DHCP, and TUN/TAP virtual devices."
Ich habe es selber ne Weile lang benutzt und war sehr zufrieden damit, vor allem laeufts (im Gegensatz zu tinc) auch unter *BSD und anderen. Leider haben ein paar Bekannte die Erfahrung gemacht, dass es deren Router abschiesst, aber das muss man selbst ausprobieren.
Du könntest Dich auch mal auf der Homepage von Spenneberg umschauen.
Stephan.
Stephan Maka schrieb:
Andreas Kretschmer wrote:
Wenn Du es wirklich hinter NAT betreiben willst, solltest Du Dir Alternativen wie tinc, OpenVPN oder so ansehen, weiß allerdings jetzt nicht aus dem Steggreif, welche NAT-fest sind.
Von http://openvpn.sourceforge.net/: "As a user-space VPN daemon, OpenVPN is compatible with with SSL/TLS, RSA Certificates and X509 PKI, NAT, DHCP, and TUN/TAP virtual devices."
Da wäre nur zu erwähnen, dass die genannten Alternativen zu ipsec eine kryptografische Katastrophe sind. ssh ist zwar im Prinzip OK, allerdings ist die Implementierung zu furchtbar, dass man die Korrektheit kaum überprüfen kann. :-( IPSEC über NAT kann man wie schon gesagt mit einem UDP-Tunnel hinbekommen. Im Tunnel kann man die IP-Adressen dann selbst festlegen.
Torsten
Torsten Werner wrote:
Da wäre nur zu erwähnen, dass die genannten Alternativen zu ipsec eine kryptografische Katastrophe sind. ssh ist zwar im Prinzip OK, allerdings ist die Implementierung zu furchtbar, dass man die Korrektheit kaum überprüfen kann. :-( IPSEC über NAT kann man wie schon gesagt mit einem UDP-Tunnel hinbekommen. Im Tunnel kann man die IP-Adressen dann selbst festlegen.
SSL/TLS ist eine kryptographische Katastrophe? Oh, dann ist das ja schlimm, dass das soweit verbreitet ist.
IPSec ueber UDP wuerde mich sehr interessieren, hab allerdings noch nichts dazu gefunden. Ich benutze KAME. Mein ISP gibt mir (fuer den fuer mich bezahlbaren Tarif) nur eine geNATtete Adresse und uebersetzt auch die gaengigen Tunnelprotokolle (GRE, IPEncap, ...) nicht. Zur Zeit bewerkstellige ich das mit PPP ueber TCP, aber IPSec ueber UDP waehre wohl praktischer... OpenVPN faellt aufgrund der genannten Instabilitaeten raus. :-(
Stephan.
Stephan Maka schrieb:
SSL/TLS ist eine kryptographische Katastrophe? Oh, dann ist das ja schlimm, dass das soweit verbreitet ist.
Nein, das habe ich nicht geschrieben. OpenSSL/SSH ist unlesbar implementiert, was es schwer macht, die Korrektheit der Implementation zu prüfen. Ansonsten ist es vom Design her ziemlich OK. Alle anderen Alternativen zu IPSEC sind dagegen schon vom Design her problematisch.
Torsten
Andreas Kretschmer [2004-06-27, 10:36 +0200]:
am Fri, dem 25.06.2004, um 18:43:51 +0200 mailte Martin Pitt folgendes:
Hi,
Wenn Du es wirklich hinter NAT betreiben willst, solltest Du Dir Alternativen wie tinc, OpenVPN oder so ansehen, weiß allerdings jetzt nicht aus dem Steggreif, welche NAT-fest sind.
Beide.
Gruß,
Frank
IPSec und NAT passen nicht gut zusammen. Aber es gibt NAT-Traversal für IPSec, aber ... keine Ahnung.
OpenVPN ist 'ne gute Alternative. Oder, wie Andreas schon sagt: SSH.
Heiko
lug-dd@mailman.schlittermann.de
-
Andreas Kretschmer -
Christian Perle -
Frank Becker -
Heiko Schlittermann -
Martin Pitt -
Stephan Maka -
Torsten Werner