[Problem] VPN 7490 <-> Linux kein Traffic

Basti.G

Neuer User
Mitglied seit
13 Aug 2014
Beiträge
5
Punkte für Reaktionen
0
Punkte
0
Hallo IP Phone Forum :huhu:,

nach dem Update auf OS 6.20 habe ich beschlossen mir (wieder mal) die VPN Konfiguration vorzunehmen. Schon mal vorab: der Tunnel kommt hoch, die SA's scheinen vernünftig ausgehandelt zu werden - aber es läuft kein Traffic über den Tunnel bzw. erst nach dem ersten Re-Keying.

Hier die Details, weiter unten noch genauere Fehlerbeschreibung und tcpdump:

Peer A:
Fritz!Box 7490 @ Fritz!OS 6.20
Dynamische IP (<Dyn IP>), mit DynDNS via myfritz (<DynDNS>)
Lokale IP / lokales Netz: 192.168.10.1 / 24

Peer B:
Linux VPS (ArchLinux, Kernel 3.15.8-1, getestet mit StrongSwan 5.2.0 und ipsec-tools/racoon 0.8.2-2)
Statische IP (<Linux IP>)
Lokale IP / lokales Netz: 192.168.20.1 / 24

Fritz!Box vpn.cfg:
Code:
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "Linux VPS";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = [B]<Linux IP>[/B];
                remote_virtualip = 0.0.0.0;
                keepalive_ip = 192.168.20.1;
                localid {
                        fqdn = "[B]<DynDNS>[/B]";
                }
		remoteid {
			ipaddr = "[B]<Linux IP>[/B]";
		}
                mode = phase1_mode_idp;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "[B]<PSK>[/B]";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.10.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.20.0;
                                mask = 255.255.255.0;
                        }
                }
		phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.20.0 255.255.255.0";
        }

Linux ipsec.conf:
Code:
# ipsec.conf - strongSwan IPsec configuration file

config setup
	listen=[B]<Linux IP>[/B]
	# strictcrlpolicy=yes
	# uniqueids = no

conn home
	keyexchange=ikev1
	#
	left=[B]<Linux IP>[/B]
	leftsubnet=192.168.20.0/24
	#
	ike=aes256-sha-modp1024!
	esp=aes256-sha1-modp1024!
	#
	right=%[B]<DynDNS>[/B]
	rightid=@[B]<DynDNS>[/B]
	rightsubnet=192.168.10.0/24
	#
	ikelifetime=1h
	keylife=1h
	#
	authby=psk
	auto=add

Ausgabe von ipsec statusall:
Code:
Connections:
home:  [B]<Linux IP>...<DynDNS>[/B],0.0.0.0/0,::/0  IKEv1
home:   local:  [B][<Linux IP>][/B] uses pre-shared key authentication
home:   remote: [B][<DynDNS>][/B] uses pre-shared key authentication
home:   child:  192.168.20.0/24 === 192.168.10.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
home[1]: ESTABLISHED 14 minutes ago, [B]<Linux IP>[<Linux IP>][/B]...[B]<Dyn IP>[<DynDNS>][/B]
home[1]: IKEv1 SPIs: 2b1ea0e9812e7e3a_i 74fe849745de1632_r*, pre-shared key reauthentication in 28 minutes
home[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
home{1}:  INSTALLED, TUNNEL, ESP SPIs: ce9028ee_i d7ab977f_o
home{1}:  AES_CBC_256/HMAC_SHA1_96, 74384 bytes_i (885 pkts, 1s ago), 74384 bytes_o (885 pkts, 1s ago), rekeying in 28 minutes
home{1}:   192.168.20.0/24 === 192.168.10.0/24

Ausgabe von ip xfrm policy:
Code:
src 192.168.10.0/24 dst 192.168.20.0/24 
	dir fwd priority 2883 
	tmpl src [B]<Dyn IP>[/B] dst [B]<Linux IP>[/B]
		proto esp reqid 2 mode tunnel
src 192.168.10.0/24 dst 192.168.20.0/24 
	dir in priority 2883 
	tmpl src [B]<Dyn IP>[/B] dst [B]<Linux IP>[/B]
		proto esp reqid 2 mode tunnel
src 192.168.20.0/24 dst 192.168.10.0/24 
	dir out priority 2883 
	tmpl src [B]<Linux IP>[/B] dst [B]<Dyn IP>[/B]
		proto esp reqid 2 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket out priority 0 
src ::/0 dst ::/0 
	socket in priority 0 
src ::/0 dst ::/0 
	socket out priority 0 
src ::/0 dst ::/0 
	socket in priority 0 
src ::/0 dst ::/0 
	socket out priority 0

Vielleicht auch interessant, hier die Ausgabe von tcpdump -i any -n "host <Dyn IP> and port not 22" während vom Fritz!Box Netz aus ein ping 192.168.20.1 läuft:
Code:
13:53:38.610352 IP [B]<Dyn IP>[/B] > [B]<Linux IP>[/B]: ESP(spi=0xc6c6e35f,seq=0xa89), length 132
13:53:38.610477 IP [B]<Linux IP>[/B] > [B]<Dyn IP>[/B]: ESP(spi=0xaf692d11,seq=0xa89), length 132
13:53:38.622172 IP [B]<Dyn IP>[/B] > [B]<Linux IP>[/B]: ICMP host [B]<Dyn IP>[/B] unreachable - admin prohibited filter, length 36

Die ersten beiden Zeilen enthalten das ICMP/Ping Paket, und in der dritten Zeile teilt die Fritz!Box dem Linux Server mit, dass sie nicht erreichbar sei, das verstehe ich nicht ...

Noch ein bisschen merkwürdiger: warte ich bis zum Re-Keying von StrongSwan, dann geht der Ping (und auch anderer Traffic) mit ~15ms durch den Tunnel, ohne dass irgendwas geändert wurde. Mit Racoon konnte ich das nicht nachstellen, da bleibt es bei admin prohibited filter.

Ich erinnere mich, dass ich vor etwa einem Jahr auch schon soweit war (damals noch mit der FB 7340), dann aber auch nicht weiter kam und irgendwann frustriert aufgegeben habe... Vielleicht seht ihr ja, wo das Problem liegen könnte.

Danke schon mal - auch, dass Du bis hierher durchgehalten hast :),
Basti
 
Kleines Update:
Ein Test über 24 Stunden zeigt, dass admin prohibited filter Pakete ohne ersichtlichen Grund auch während der Key Lifetime auftreten und dann bis zum Re-Keying bestehen bleiben.

Verschluckt sich die FB da an irgendetwas? Habt ihr einen TIpp, wie ich das auf der FB besser tracen kann (telnetd läuft)?

Danke
Basti
 
admin prohibited filter Pakete ohne ersichtlichen Grund auch während der Key Lifetime auftreten
Ich kann nicht verstehen, warum die "admin prohibited filter"-ICMPs mit Deinem Ping zusammenhängen sollen. Wenn die Richtung der Pakete stimmt, müßte das ja die Antwort der FRITZ!Box auf die ICMP-Reply-Pakete des VPS sein ... das erscheint mir eher merkwürdig.

Wie wäre es (testweise, ansonsten ist AES natürlich die richtige Wahl) mit anderer ESP-Verschlüsselung und einem tcpdump in eine Datei, die Du hinterher mit Wireshark (der ESP-Dissector kann m.W. kein AES, deshalb die temporäre 3DES-Variante) dann decodieren kannst ? So siehst Du genauer, was da eigentlich in den ESP-Paketen enthalten ist. Deine ICMP-Nachricht würde dann auch aussagekräftiger werden (Schnelltest mit -vvv beim tcpdump), so geht daraus ja nicht einmal hervor, von wo nach wo (Port) das Paket eigentlich gehen sollte.

Wenn das ICMP-Paket die Antwort auf das ESP-Paket an sich und nicht auf dessen Inhalt ist, geht es wohl an einen falschen Port in der FRITZ!Box. Das würde dann darauf hindeuten, daß da (trotz FRITZ!Box-seitiger Einstellung "use_nat_t=yes") der Schlüsselaustausch (der ist ja erfolgreich abgeschlossen) und der Datenaustausch (also der ESP-Traffic) auf verschiedenen Pfaden erfolgt, was bei "nativem" IPSec der Fall wäre. Dort läuft IKE über UDP 500 und ESP "as itself". Leider kann man das in Deinem Beitrag oben nicht erkennen, da Du neben den IP-Adressen auch die Portnummern mit entfernt hast. Die FRITZ!Box ist jedenfalls sehr flexibel, was die Benutzung von NAT-T angeht und die Einstellung in der VPN-Konfiguration ist mehr eine "Erlaubnis zur Benutzung" als ein "benutze es !".

Bei funktionierendem "NAT-Traversal" kommunizieren beide Seiten nur über UDP 4500. Auf der Linux-Seite kann man das mit "nat_traversal force;" in der racoon.conf erzwingen, bei strongSwan findest Du das sicherlich selbst. Der Linux-Daemon muß dazu natürlich auch auf beiden Ports (oder meinetwegen auch nur dem NAT-T-Port) lauschen ...

Daß es nach dem reinen Rekeying dann irgendwann mal funktioniert, finde ich allerdings extrem merkwürdig, außer dabei wird dann eine getrackte Connection aktiviert, die vorher nicht bestand. Ich würde aber mehr auf einen Neuaufbau der Verbindung tippen, bei dem dann (wg. anderem Initiator) beide Seiten von derselben NAT-T-Einstellung ausgehen.

Habt ihr einen TIpp, wie ich das auf der FB besser tracen kann (telnetd läuft)?
Die Box protokolliert einiges in der Datei /var/tmp/ike.log (ältere Nachrichten in ike.old), das hilft zumindest bei der Diagnose der gröbsten Mißverständnisse.

Wenn Du noch einmal Konfigurationsauszüge postest, lasse mal bitte die Portnummern drin ... sonst ist zu viel zu raten.
 
Gleiches Phänomen hier. Die FritzBox baut eine VPN-Verbindung zu Racoon auf. Es gehen scheinbar auch Pakete durch, da auf dem Ziel-Server, mittelst netstat, auch ein Verbindungsaufbau (SYN-RECEIVED) zu sehen ist. Die Pakete scheinen aber nicht mehr an der Quelle anzukommen.

FritzBox-Konfigurationstechnisch sieht meine Konfiguration fast identisch aus. (Nutze 3DES, ohne Authentication Header, ohne Kompression, mit pfs)
phase2ss = "esp-3des-shal/ah-no/comp-no/pfs";

Was ich jetzt nicht Verstehe, wenn man sich das Raccon-Log anschaut:

Aug 13 19:19:50 <ISP-HOSTNAME> racoon: INFO: respond new phase 1 negotiation: <ISP-HOSTIP>[500]<=><LOCALDYNAMICIP>[500]
Aug 13 19:19:50 <ISP-HOSTNAME> racoon: INFO: begin Aggressive mode.
Aug 13 19:19:50 <ISP-HOSTNAME> racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Aug 13 19:19:50 <ISP-HOSTNAME> racoon: INFO: received Vendor ID: DPD
Aug 13 19:19:50 <ISP-HOSTNAME> racoon: INFO: Adding xauth VID payload.
Aug 13 19:19:50 <ISP-HOSTNAME> racoon: [<LOCALDYNAMICIP>] ERROR: notification INITIAL-CONTACT received in aggressive exchange.
Aug 13 19:19:50 <ISP-HOSTNAME> racoon: INFO: ISAKMP-SA established <ISP-HOSTIP>[500]-<LOCALDYNAMICIP>[500] spi:7566ca7a2cd6ab0a:7f4bf0ea94285982
Aug 13 19:19:50 <ISP-HOSTNAME> racoon: [<LOCALDYNAMICIP>] INFO: received INITIAL-CONTACT
Aug 13 19:19:50 <ISP-HOSTNAME> racoon: INFO: respond new phase 2 negotiation: <ISP-HOSTIP>[500]<=><LOCALDYNAMICIP>[500]
Aug 13 19:19:50 <ISP-HOSTNAME> racoon: INFO: no policy found, try to generate the policy : <LOCALNET>/24[0] <REMOTENET>/24[0] proto=any dir=in
Aug 13 19:19:50 <ISP-HOSTNAME> racoon: ERROR: invalid transform-id=4 in IPCOMP.
Aug 13 19:19:50 racoon: last message repeated 19 times
Aug 13 19:19:50 <ISP-HOSTNAME> racoon: WARNING: trns_id mismatched: my:3DES peer:AES
Aug 13 19:19:51 racoon: last message repeated 2 times
Aug 13 19:19:51 <ISP-HOSTNAME> racoon: INFO: IPsec-SA established: ESP/Tunnel <ISP-HOSTIP>[500]-><LOCALDYNAMICIP>[500] spi=32529397(0x1f05bf5)
Aug 13 19:19:51 <ISP-HOSTNAME> racoon: INFO: IPsec-SA established: ESP/Tunnel <ISP-HOSTIP>[500]-><LOCALDYNAMICIP>[500] spi=3446836426(0xcd728cca)

Laut diesem eintrag im Log „ERROR: invalid transform-id=4 in IPCOMP.“ Nutz er doch die Kompression. Laut http://www.iana.org ist ID 4 = LZJH die Racoon nicht kann bzw. unterstützt. Hier wird nur deflate unterstützt...

Weiter will die FritzBox scheinbar doch AES verschlüsseln. Siehe Log: „trns_id mismatched: my:3DES peer:AES

Es existiert jetzt bei AVM ein PDF in dem alle unterstützten IPSEC-Strategien für die Phase2 aufgeführt sind. Hatte jetzt auch schon einige durch probiert allerdings immer mit dem Resultat, dass der Kanal immer mit Kompression und AES Verschlüsselung aufgebaut wird.
Mit dem älteren Software Stand auf der FtitzBox läuft alles so wie es soll....
 
Zuletzt bearbeitet:
AVM hat halt irgendwann auf dem Weg zur 06.20 die IPSec-Strategien in der /etc/default.$CONFIG_PRODUKT/$OEM/ipsec.cfg angepaßt.

Wer eine alte Proposal-Auswahl verwendete, die nun nicht mehr enthalten ist (in #4 steht etwas von "esp-3des-sha1/ah-no/comp-no/pfs", in der ipsec.cfg der 06.23 heißt das Bouquet "esp-3des-sha/ah-no/comp-no/pfs"), der fällt vielleicht inzwischen nicht mehr schon beim Import auf die Nase (so steht es bei AVM beschrieben), sondern erst bei der Auswahl der Proposals?

Wenn (Achtung Theorie, nicht getestet) nun AVM an dieser Stelle einen "off by one"-Fehler in der nach Stärke der Verschlüsselung sortierten Liste der Proposals hat, wäre das ja eine Erklärung für das Phänomen. Das müßte sich genauer untersuchen lassen (wenn man nicht einfach wie AVM in den Quelltext schauen kann), indem man sich selbst eine Liste mit Proposals macht und dort verschiedene AES256-Möglichkeiten einbaut. Geht dann nur die erste nicht, wird "off by one" wahrscheinlicher (das könnte auch erklären, warum es beim Rekeying dann klappt) ... ändert das nichts und AES256 wird auch als "zweite Wahl" am Beginn der Verbindung nicht richtig akzeptiert, ist meine Theorie Bullshit. So ein "off-by-one" kann ja genauso gut auch in der Sortierung der Liste stecken (bzw. im Aufruf einer solchen Sortierung, denn das wird wohl kaum mehrfach implementiert sein) ... als These für das abweichende Verhalten zwischen "init" und "rekey" taugt das allemal. Eine weitere Möglichkeit wäre dann der Test mit nur einem Proposal (was den Namen dann ja eigentlich nicht mehr verdient ;)); allerdings könnte da natürlich vor dem Aufruf einer Sortierung auch ohne weiteres eine Abfrage auf die Anzahl der Einträge stecken, was die Evidenz dieses Tests schon gewaltig in Frage stellen kann.
 
Die Möglichkeit besteht natürlich ... bloß zweifel ich mittlerweile auch an mir selber: hab nochmal an der Config rumgebastelt um evtl. noch ein paar Belege zu finden für den off-by-one.
Mit dem Neustart des Service haben sich die Peers plötzlich auch auf aes256 verständigen können, egal ob als einziges Proposal, an erster Stelle oder wo anders... die Config hat mittlerweile auch Neustarts von sowohl FB als auch vServer überstanden. Das freut mich jetzt natürlich, am Schlauch stehe ich trotzdem (nein, strongSwan oder Kernel Update gab es heute bzw. vor dem Neustart keines...)
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.