IPsec-tools für freetz (ohne AVM VPN)

[MaxMuster]

Moin zusammen,

hier mal Paket für ipsec im freetz für die älteren Boxen zusammen mit einer absolut simplen GUI dafür. Entstanden aus der Idee in diesem Thread. Basiert jetzt auf der Version 0.7.2.
Zu beachten dabei:
- Das Paket lädt beim Starten stumpf alle Module in net und crypto
- die geladenen Module werden nicht wieder entladen
- Die GUI ist ein absoluter Schnellschuss, um die Funktion zu testen. Vor allem muss die Config von Hand "reingapastet" werden
- Für "setkey" gibt es zwar ein Konfig-File, das wird aber (noch) nirgends geladen
- Getestet (und Kernel-config-änderungen) sind nur für Version 0.33 und 0.49 dabei. Für anderen wären die Kernel-Module aus dem Patch (in NET und CRYPTO) hinzuzufügen oder die Dinge fest in den Kernel aufzunehmen..

Falls mal jemand bereit wäre oder Lust hätte zu testen...

Jörg

 

[mehle]

Interessante Idee, aber wie soll man von aussen denn via ESP und/oder AH auf die Box kommen. Kann den der Paketfilter im dsld diese Protokolle überhaupt bearbeiten?

Ciao
Stephan

 

[MaxMuster]

Interessanter Einwurf, ich habe bislang ja erstmal nur im LAN getestet. Was der dsld damit macht, weiß ich nicht, ich hätte erstmal gedacht eine Portweiterleitung von Port 500 und 4500 auf sich selbst würde reichen?
Wie das dann mit ESP ist, habe ich nicht bedacht. Evtl müsste man dann tatsächlich den dsld rausschmeißen.

Wie gesagt, nicht getestet, ich habe momentan keine FB, die den Internetzugang macht...


Jörg

 

[mehle]

Port 500/4500 ist NUR für IKE.

Das eigentliche IPSEC ist ein Protokol (eigentlich 2: ESP und AH, aber heute sieht man fast ausschliesslich nur noch ESP), welches entsprechend ISO/OSI NEBEN IP läuft, d.h. es ersetzt IP!

Ciao
Stephan

 

[MaxMuster]

... ja, fiel mir dann auch ein, dass es ja um das ESP-Protokoll geht, siehe mein Edit oben, was sich mit deinem Beitrag überschnitten hatte...
Ggfls. müsste/könnte man IPsec over TCP nutzen..

Jörg

 

[mehle]

IPSEC over TCP, hm, nimm doch besser OpenVPN - IPSEC ist so schon komplex und fehleranfällig genug, da bringt jegliche zusätzliche Komplexität nur noch mehr Unglück. ;-)

Ausserdem hast du keine Probleme beim NAT mit OpenVPN.

Ciao
Stephan

 

[MaxMuster]

Naja, für das ESP-Tunneln ist ja NAT-Traversal auf UDP 4500 durchaus gängig...
Aber momentan ist das ja eh reine Spekulation. Keine Ahnung, was der dsld mit einem IP Paket mit "Protokoll 50" so macht ;-).
Wenn ich mal etwas Zeit habe, versuche ich das mal mit einer "Internetbox" zu testen.

Ansonsten: Ich nutze schon immer OpenVPN, das IPSec-Thema ist reiner "Sport" ;-)

Jörg

EDIT: Da ich in der Firmware schon ESP "forwarden" kann, sollte das doch auch auf die eigene Box (0.0.0.0) klappen, denke ich per

"esp 0.0.0.0 0.0.0.0"

 

[mehle]

Na gut, ich ziehe meine Bedenken zurück

Ciao
Stephan

 

[MaxMuster]

Auch wenn es keinen interessiert ;-), hier mal ein Stand von heute. Leicht erweiterte "GUI", momentan ganz speziell für meine Tests erweitert:

- PSP-File zusätzlich
- Angabe eines "DynDNS"-Namens und lokaler/entfernter VPN-IPs erzeugt beim Aufruf einen setkey-Eintrag dazu (für den "roadwarrior"). Dabei wir momentan die IP zum Default-GW ebenfalls von Skript ermittelt, das sollte/wollte ich wohl noch ändern, denn im conf-file habe ich ja den Listen Eintrag sowieso und wenn die Einträge differieren, geht nix ..
- setkey.conf wird geladen
- Pfad für control socket /var/run/racoon/racoon.sok
.....

Bei mir funktionierte ein Test mit einer "Server-Eumex" am DSL mit auf sich selbst (0.0.0.0) "geforwardeten" esp und UDP[500] und UDP[4500] (mehles Vermutung mit dem Problemen durch den dsld waren nicht unberechtigt, die Kiste muss auf dieser AVM-Pseudo-DSL-IP 169.254.2.1 lauschen...) . Die Client-Eumex steht hinter einem anderen Router im LAN als IP-Client. ESP-Forwarding wäre vermutlich nicht nötig, da die Konstellation hier NATT nutzt.

Hier mal die genutzen Dateien des Servers:

#racoon.conf:
path pre_shared_key "/mod/etc/racoon/certs/psk.txt";
path certificate "/mod/etc/racoon/certs";
log notify ; # error warning notify debug debug2

listen {
        adminsock "/var/run/racoon/racoon.sock" "root" "operator" 0660;
        isakmp 169.254.2.1 [500];
        isakmp_natt 169.254.2.1 [4500];
}

remote anonymous {
	exchange_mode aggressive;
	my_identifier user_fqdn "office";
	nat_traversal on;
	ike_frag on;
	passive on;
	generate_policy on;
	nonce_size 16;
	proposal {
		encryption_algorithm aes;
		hash_algorithm sha1;
		authentication_method pre_shared_key;
		dh_group 2;
		lifetime time 1 hour;
	}
}

sainfo anonymous {
	pfs_group 2;
	lifetime time 1 hour;
	compression_algorithm deflate;
	encryption_algorithm aes;
	authentication_algorithm hmac_sha1, non_auth;
}

#setkey.conf
flush;
spdflush;
spdadd 10.100.1.0/24 10.100.1.2/32 any -P out ipsec esp/tunnel/169.254.2.1-0.0.0.0/require;
spdadd 10.100.1.2/32 10.100.1.0/24 any -P in  ipsec esp/tunnel/0.0.0.0-169.254.2.1/require;

# PSK file
office	geheim
home	geheim

Beim "Client"

path pre_shared_key "/mod/etc/racoon/certs/psk.txt";
path certificate "/mod/etc/racoon/certs";
log debug; # error warning notify debug debug2

listen {
        adminsock disabled;
        isakmp 192.168.178.123 [500];
        isakmp_natt 192.168.178.123 [4500];
}

remote anonymous {
	exchange_mode aggressive;
	my_identifier user_fqdn "home";
	nat_traversal on;
	ike_frag on;
	generate_policy on;
	proposal {
		encryption_algorithm aes;
		hash_algorithm sha1;
		authentication_method pre_shared_key;
		dh_group 2;
		lifetime time 1 hour;
	}
}

sainfo anonymous {
	pfs_group 2;
	lifetime time 1 hour;
	compression_algorithm deflate;
	encryption_algorithm aes;
	authentication_algorithm hmac_sha1, non_auth;
}

Die setkey-Einträge macht das Start-Skript, daher hier nur die flush-Befehle. In der GUI sind DynDNS-Name sowie local_vpn (10.100.1.2/32) und remote_vpn(10.100.1.0/24) eingetragen

# setkey.conf
flush;
spdflush;

# PSK file
office	geheim
home	geheim

Jörg

EDIT: Gerade noch Fehler in Patches gefunden, unten gibt es einen korrigierten Anhang.

 

[zeus-cu]

Hallo Jörg,

den Beitrag von Dir finde ich sehr interessant. Ich bin im Besitz einer Fritz Fon 7150 und mich ärgert es schon sehr lange, dass AVM keine Anstalten unternimmt ipsec für diese Box zu implementieren. Aus diesem Grund habe ich noch einen zweiten Router der das übernimmt. :-(
Leider habe ich es nicht hinbekommen deinen ipsec-patch ins freetz Kernel zu integrieren. Auch sagen mir die Versionsangaben aus deiner ersten Post 0.7.2, 0.33 und 0.49 gar nichts. Ich habe es mit freetz1.1 (trunk) versucht (da wird erst die aktuelle FW fritz.fon_7150.annexb.38.04.71.image unterstützt). Kannst Du mir erklären wie Du den Patch erzeugt hast. Eventuell schaffe ich es ja ihn für meine Zwecke anzupassen?

Danke.

Gruß
Klaus

 

[MaxMuster]

Hi,

erzeugt ist der mit "svn diff", allerdings im Trunk.

Ich versuche es mal zu beschreiben...
- Hast du den Patch von oben versucht? Der baut das ins Freetz-Menu mit ein (macht einen Eintrag in make/Config.in). Wenn der nicht dirn ist, mache das einfach von Hand, so dass die Datei make/Config.in unter "Testing" den zusätzlichen Eintrag hat

source make/inotify-tools/Config.in
source make/iodine/Config.in
[B]source make/ipsec-tools/Config.in[/B]
source make/iptraf/Config.in
source make/irssi/Config.in

- Entpacke das tgz-File aus dem Beitrag davor in den freetz make-Ordner
- Dann musst du vermutlich noch den Kernel anpassen ("replace Kernel" ist Voraussetzung für IPsec): Mit einem "make kernel-menuconfig" rufst du die Konfig des Kernels auf. Dort musst du diese Dinge anwählen:
Unter "Networking-> Networking Options":
IPsec user configuration interface, PF_KEY sockets, IP: AH transformation, IP: ESP transformation und (nicht zwingend) IP: IPComp transformation
Unter Cryptographic options:
HMAC support, Null algorithms, MD5 digest algorithm, SHA1 digest algorithm, SHA256 digest algorithm, DES and Triple DES EDE cipher algorithms, AES cipher algorithms, Deflate compression algorithm
Als "Modul" (<m>) bist du etwas flexibler, festes einbauen in den Kernel (<*>) macht das ganze etwas kleiner.

Dann solltes du bei "make menuconfig" mit advanced und replace Kernel unter "Testing" die ipsec-tools auswählen können.

Jörg

EDIT: Ach ja, deine "Versionsfragen" ;-): 0.7.2 ist die Version der ipsec-tools, die den ike-Deamon, das setkey-Toolt usw enthalten. Die x.06.33 und x.06.49 sind AVM Firmware-Versionen, die ich genutzt habe für Eumex300IP ("Fritzbox-FON") und auf einer 7050.

 

[MaxMuster]

Hab gerade gemerkt, dass es bei neuerem Kernel/uclib Probleme mit "GLOB_TILDE" gibt. Auch funktioniert "statisch" bei der 0.7.2 Version nicht, weil ich den Patch nicht angepasst hatte. Schande über mich...

Mit diesem "make/ipsec-tools" Ordner (und dessen Patches) solle es gehen, weils neu ist ausnahmsweise in eimem neuen Beitrag.

Jörg

 

[zeus-cu]

Hallo Jörg,

vielen Dank für die Doku und die neuen ipsec-tools. Ich hatte gestern abend genau das Problem, dass GLOB_TILDE nicht gefunden wurde. Jetzt hat alles einwandfrei funktioniert. Werde das neue Image mal auf die Box laden und dann testen. Ergebnis poste ich dann.

Gruß

Klaus

 

[zeus-cu]

Noch eine kurze Frage:

Ich kann im Kernel leider die Crypto API und HMAC Support nicht aktivieren. Weder als Modul noch fest in den Kernel. Vor beiden Optionen steht ein "---"
Welche Abhänigkeiten müssen erfüllt sein damit ich das auswählen kann? In der Help steht z.B. bei Crypto API:

Selected by: INET_ESP && NET && INET

Gruß
Klaus

 

[Silent-Tears]

Tja, bei "---" ist es schon aktiviert.

 

[zeus-cu]

Zwar kann ich noch keinen Erfolg vermelden, dass ich den VPN mit ipsec am Start habe (no proposal choosen) aber bin mir sicher das dies noch wird. Die Weboberfläche ist zwar ein wenig rudimentär aber eigentlich völlig ausreichend.
Vielen Dank nochmal an Jörg.
Kann es sein das die Box beim IKE den Port 500 udp incoming per NAT einfach blockt?

Gruß
Klaus

 

[MaxMuster]

Alle eingehenden Ports werden geblockt, die nicht explizit weitergeleitet werden. Du müsstest also udp500, bei NATT udp4500 und wenn es ohne NATT gehen soll wohl auch das Protokoll "esp" auf die Box selbst weiterleiten (auf 0.0.0.0). Am besten die Einträge in der Weiterleitungs-GUI alle auf eine Dummy-IP umleiten und die dann in der ar7.cfg auf 0.0.0.0 ändern. Oder du nutzt den GUI-Patch, so dass du in der AVM-GUI direkt 0.0.0.0 als Ziel eintragen kannst (siehe hier)

Jörg

 

[JB82]

Hallo zusammen!

Mich interessiert das auch brennend, ärgerts mich doch schon lange, dass AVM die Weiterentwicklung der 7050 gänzlich eingestellt hat und ich so nicht in den Genuss eines VPN-Servers komme.

Zugegeben, einen VPN-Server könnte ich zwar mit OpenVPN draufsetzen, doch ist mein Ziel eine LAN-LAN-Kopplung mit einer Original-7170, welche nicht mir gehört und ich dementsprechend nicht anpassen darf. OpenVPN scheidet für mich daher aus und die AVM-Software ist ja leider nur ein Client...

Im Moment habe ich grad nicht ausreichend Zeit, um mich wieder in die Bearbeitung der Fritz!Box einzuarbeiten (bislang bloß Pakete nachladen mittels ar7...), hoffe das Projekt ist noch nicht eingestellt?

Kann ich das Paket auch per Nachladen auf meiner 7050 testen oder muss ich dafür den freetz installieren? Ganz so tiefe Eingriffe ins System wollte ich eigentlich vermeiden...

Viele Grüße
Jens

 

[MaxMuster]

Ohne neuen Kernel (bei freetz: "replace kernel") wird das nicht gehen, weil einige benötigte Dinge nicht im AVM-Kernel enthalten sind...

Jörg

 

[JB82]

Hallo Jörg, danke für Deine Antwort.

Dann werd ich mich da bei Gelegenheit ransetzen, freu mich schon auf eine vernünftige LAN-LAN-Kopplung

Viele Grüße
Jens