Site to Site VPN Fritzbox 7490<->Watchguard X750E

[mactwo]

Hallo zusammen.

Ich versuche nun schon eine Weile eine FB7490 (OS6.92) mit einer Watchguard X750E (Fireware XTM 11.3.8) per VPN zu verbinden.
Ich scheitere bisher aber leider mit allem was ich versucht habe. Google bringt leider auch nur sehr wenige Anleitungen, welche aber auch nicht funktioniert haben.

Ich habe eine Config für die FB erstellt:

Spoiler: FB Config

vpncfg {
connections {
enabled = yes;
conn_type = conntype_lan;
name = "remote-dyndns.adresse.xx";
always_renew = yes;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = remote-dyndns.adresse.xx;
remote_virtualip = 0.0.0.0;
localid {
ipaddr = lokale.dyndnsadresse.xx;
}
remoteid {
ipaddr = remote-dyndns.adresse.xx;
}
mode = phase1_mode_aggressive;
phase1ss = "def/3des/sha";
keytype = connkeytype_pre_shared;
key = "derganzsichereschluessel";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.200.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.100.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-3des-sha/ah-no/comp-no/no-pfs";
accesslist = "permit ip any 192.168.100.0 255.255.255.0";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
}
// EOF

Die Watchguard ist folgendermaßen konfiguriert.



Jetzt bekomme ich im Log der WG folgendes:

2018-01-04 21:17:50 iked ******** RECV an IKE packet at xx.xx.xx.xx:500(socket=11 ifIndex=4) from Peer xx.xx.xx.xx:500 ********      Debug
2018-01-04 21:17:50 iked Found IKE Policy xxx, dev=eth6] for peer IP=xx.xx.xx.xx, numXform=1, pkt ifIndex=4      Debug
2018-01-04 21:17:50 iked WARNING: Rejected phase 1 aggressive mode from xx.xx.xx.xx to 192.168.xx.xx (no matching policy) cookies i=28c4f8e5 6f580f90 r=00000000 00000000      Debug

Die Fritzbox scheint also eine Verbindung aufbauen zu wollen, aber dann lehnt die Watchguard diesen Versuch ab.
Hier komme ich im Moment nicht weiter.
Kann mir bitte jemand sagen woran es scheitert?

Gruß

 

[PeterPawn]

In den Screenshots kann man zwar wenig erkennen (die Schrift ist schon sehr klein und dünn), aber Dir ist schon bewußt, daß DES und 3DES (aka Triple-DES) zwei verschiedene Verschlüsselungen sind, auch wenn sie auf ähnlichen "Rechenvorschriften" basieren? Und das dieses genauso auch für Hash-Algorithmen gilt, wo MD5 und SHA dann nur noch geringe Gemeinsamkeiten aufweisen?

Wenn die Einstellungen im Screenshot stimmen, versuchst Du gerade eine FRITZ!Box mit einem einzigen Proposal (das Profil "esp-3des-sha/ah-no/comp-no/no-pfs" enthält tatsächlich nur 3DES mit SHA(1), wenn man in die "ipsec.cfg" in der Firmware sieht) mit einer WG-Firewall mit DES und MD5 zu verkuppeln - und das gilt sogar (wenn ich die WG-Einstellungen richtig interpretiere anhand der paar Bildchen) für beide Phasen der Schlüsselaushandlung.

Das ist keine Katalogbraut und wenn die beiden nicht auf eine gemeinsame Sprache kommen (no matching policy), wird aus der Verbindung ziemlich sicher niemals eine glückliche Familie.

Und auch auf das "ipaddr" als Identifikation in P1 (in der FRITZ!Box-Konfiguration) würde ich mich nicht versteifen, solange ich das nicht funktionsfähig gesehen habe ... wenn da tatsächlich der Domain-Name verwendet wird (man weiß halt nicht, wie weit Du da die "Maskierung" getrieben hast und ob hinter "ipaddr" nun eine Adresse oder doch ein Domain-Name steht, wie diese "Maskierung" es vermuten läßt - und auch das erste Bildchen würde dazu passen, wenn da die Verwendung des Domain-Namens ausgewählt wurde), wäre ein Type "fqdn" um einiges wahrscheinlicher - das sind am Ende unterschiedliche Tags für "ipaddr" und "fqdn" im Payload beim IKE (siehe RFC für IPSec v1).

 

[mactwo]

Danke für die schnelle Antwort.

das mit fqdn<>ipaddr hat schon mal wieder weiter geholfen.
Ich hatte einfach eine fertige Config angepasst und das dann vergessen.
Aber zu der Config die zu importieren ist.

Wenn ich unter "remoteip = xxx.xxx.xxx.xxx;" den Dyndns-Namen eintrage, bekomme ich beim importieren einen Fehler auf der Fritzbox und die Datei wird nicht importiert.
Wie ist da die richtige Syntax?
Ich habe daher erstmal die wirklichen IPs eingetragen. Das funktioniert aber ja nicht auf Dauer wenn die sich ändert.


Ich bin jetzt aber soweit, dass auf meiner WG zumindest etwas gefunden wird.
Weiter habe ich die Möglichkeit das ganze auch noch auf einer zweiten WG testen zu können. Hier funktioniert es anscheinend.
Der Tunnel wird hier aufgebaut. Ich kann zwar noch keine Nutzdaten senden, aber das liegt an den Firewall-Rules nehme ich an.
Im Screenshot ist auch zu sehen, dass bei meiner auch gar kein Tunnel unter BOVPN angezeigt wird.
Die Einstellungen der WG auf der es funktioniert habe ich im Bezug auf den Tunnel 1:1 übernommen.

Spoiler: Log meiner WG

2018-01-05 09:20:12 iked ******** RECV an IKE packet at x.x.x.x:500(socket=11 ifIndex=4) from Peer y.y.y.y:500 ********      Debug
2018-01-05 09:20:12 iked Found IKE Policy [rene, dev=eth6] for peer IP=y.y.y.y, numXform=1, pkt ifIndex=4      Debug
2018-01-05 09:20:12 iked AggrMode: match addr|ID|if pcy [rene] if=4, peer y.y.y.y      Debug
2018-01-05 09:20:12 iked After id match, use IKE Policy [rene, dev=eth6] for peer IP=y.y.y.y, numXform=1, pkt ifIndex=4      Debug
2018-01-05 09:20:12 iked AggrMode: recv 1st msg pcy [rene] peer y.y.y.y:500 (Ct=466)      Debug
2018-01-05 09:20:12 iked Phase 1 started by peer with policy [rene] from y.y.y.y:500 aggressive mode      Debug
2018-01-05 09:20:12 iked  Sending second message with policy [rene] to y.y.y.y:500 aggressive mode      Debug
2018-01-05 09:20:24 iked Drop negotiation to peer y.y.y.y:500 due to phase 1 retry timeout      Debug
2018-01-05 09:21:02 iked ikePcyName(rene)'s dns resolved addr=y.y.y.y      Debug
2018-01-05 09:21:02 iked the learned dynamic peer ip for the domain name(rene.dyn.dns) is changed (oldIP=77.188.35.233, newIP=y.y.y.y)      Debug
2018-01-05 09:21:02 iked in the dynamic IP cache, add ikePcy(rene): rene.dyn.dns<-->ip(y.y.y.y)      Debug
2018-01-05 09:21:02 iked AUTOSTART: RECV ipecPcy(rene), ikePcy(rene), ifIndex(4), tunnel_src=x.x.x.x, tunnel_dst=y.y.y.y      Debug
2018-01-05 09:21:02 iked IkeFindIsakmpSABySPD: (opCode 1) search pcy [rene] with src=x.x.x.x dst=y.y.y.y, p1saId=0 peer_udp=0      Debug
2018-01-05 09:21:02 iked From IPSEC tunnel_src=x.x.x.x, tunnel_dst=y.y.y.y, ifindex=4      Debug
2018-01-05 09:21:02 iked IkeFindIsakmpSABySPD: (opCode 1) search pcy [rene] with src=x.x.x.x dst=y.y.y.y, p1saId=0 peer_udp=0      Debug
2018-01-05 09:21:02 iked Starting phase 1 negotiation using  [rene] to y.y.y.y:500 aggressive mode      Debug
2018-01-05 09:21:02 iked ikePcyName(rene)'s dns resolved addr=y.y.y.y      Debug
2018-01-05 09:21:02 iked in the dynamic IP cache, add ikePcy(rene): rene.dyn.dns<-->ip(y.y.y.y)      Debug
2018-01-05 09:21:02 iked ike_config_ipsecPolicy_download_SPs: BOVPN update localIp=x.x.x.x, peerIp=y.y.y.y      Debug
2018-01-05 09:21:02 iked ike_config_ipsecPolicy_download_SPs: choose tunnelLocalIP(x.x.x.x), tunnelRemoteIP(y.y.y.y), outIfIndex(4), outIfnum(6), outIfmark(0x10006)      Debug
2018-01-05 09:21:02 iked ike_config_ipsecPolicy_download_SPs: outbound TMPL: daddr=y.y.y.y, spi=0x0, proto=50, family=2, saddr=x.x.x.x, reqid=0, mode=1      Debug
2018-01-05 09:21:02 iked ike_config_ipsecPolicy_download_SPs: inbound TMPL: daddr=x.x.x.x, spi=0x0, proto=50, family=2, saddr=y.y.y.y, reqid=0, mode=1      Debug
2018-01-05 09:21:02 iked ******** RECV an IKE packet at x.x.x.x:500(socket=11 ifIndex=4) from Peer y.y.y.y:500 ********      Debug
2018-01-05 09:21:02 iked Found IKE Policy [rene, dev=eth6] for peer IP=y.y.y.y, numXform=1, pkt ifIndex=4      Debug
2018-01-05 09:21:02 iked Received inform notify : (Invalid ID Information) from y.y.y.y:500.      Debug
2018-01-05 09:21:05 iked ******** RECV an IKE packet at x.x.x.x:500(socket=11 ifIndex=4) from Peer y.y.y.y:500 ********      Debug
2018-01-05 09:21:05 iked Found IKE Policy [rene, dev=eth6] for peer IP=y.y.y.y, numXform=1, pkt ifIndex=4      Debug
2018-01-05 09:21:05 iked Received inform notify : (Invalid ID Information) from y.y.y.y:500.      Debug
2018-01-05 09:21:08 iked ******** RECV an IKE packet at x.x.x.x:500(socket=11 ifIndex=4) from Peer y.y.y.y:500 ********      Debug
2018-01-05 09:21:08 iked Found IKE Policy [rene, dev=eth6] for peer IP=y.y.y.y, numXform=1, pkt ifIndex=4      Debug
2018-01-05 09:21:08 iked Received inform notify : (Invalid ID Information) from y.y.y.y:500.      Debug
2018-01-05 09:21:11 iked ******** RECV an IKE packet at x.x.x.x:500(socket=11 ifIndex=4) from Peer y.y.y.y:500 ********      Debug
2018-01-05 09:21:11 iked Found IKE Policy [rene, dev=eth6] for peer IP=y.y.y.y, numXform=1, pkt ifIndex=4      Debug
2018-01-05 09:21:11 iked Received inform notify : (Invalid ID Information) from y.y.y.y:500.      Debug
2018-01-05 09:21:14 iked Drop negotiation to peer y.y.y.y:500 due to phase 1 retry timeout      Debug
2018-01-05 09:21:14 iked ikePcyName(rene)'s dns resolved addr=y.y.y.y      Debug
2018-01-05 09:21:14 iked in the dynamic IP cache, add ikePcy(rene): rene.dyn.dns<-->ip(y.y.y.y)      Debug
2018-01-05 09:21:14 iked AUTOSTART: RECV ipecPcy(rene), ikePcy(rene), ifIndex(4), tunnel_src=x.x.x.x, tunnel_dst=y.y.y.y      Debug
2018-01-05 09:21:14 iked IkeFindIsakmpSABySPD: (opCode 1) search pcy [rene] with src=x.x.x.x dst=y.y.y.y, p1saId=0 peer_udp=0      Debug
2018-01-05 09:21:15 iked From IPSEC tunnel_src=x.x.x.x, tunnel_dst=y.y.y.y, ifindex=4      Debug
2018-01-05 09:21:15 iked IkeFindIsakmpSABySPD: (opCode 1) search pcy [rene] with src=x.x.x.x dst=y.y.y.y, p1saId=0 peer_udp=0      Debug
2018-01-05 09:21:15 iked Starting phase 1 negotiation using  [rene] to y.y.y.y:500 aggressive mode      Debug
2018-01-05 09:21:15 iked ikePcyName(rene)'s dns resolved addr=y.y.y.y      Debug
2018-01-05 09:21:15 iked in the dynamic IP cache, add ikePcy(rene): rene.dyn.dns<-->ip(y.y.y.y)      Debug
2018-01-05 09:21:15 iked ike_config_ipsecPolicy_download_SPs: BOVPN update localIp=x.x.x.x, peerIp=y.y.y.y      Debug
2018-01-05 09:21:15 iked ike_config_ipsecPolicy_download_SPs: choose tunnelLocalIP(x.x.x.x), tunnelRemoteIP(y.y.y.y), outIfIndex(4), outIfnum(6), outIfmark(0x10006)      Debug
2018-01-05 09:21:15 iked ike_config_ipsecPolicy_download_SPs: outbound TMPL: daddr=y.y.y.y, spi=0x0, proto=50, family=2, saddr=x.x.x.x, reqid=0, mode=1      Debug
2018-01-05 09:21:15 iked ike_config_ipsecPolicy_download_SPs: inbound TMPL: daddr=x.x.x.x, spi=0x0, proto=50, family=2, saddr=y.y.y.y, reqid=0, mode=1      Debug
2018-01-05 09:21:15 iked ******** RECV an IKE packet at x.x.x.x:500(socket=11 ifIndex=4) from Peer y.y.y.y:500 ********      Debug
2018-01-05 09:21:15 iked Found IKE Policy [rene, dev=eth6] for peer IP=y.y.y.y, numXform=1, pkt ifIndex=4      Debug
2018-01-05 09:21:15 iked Received inform notify : (Invalid ID Information) from y.y.y.y:500.      Debug
2018-01-05 09:21:17 iked ******** RECV an IKE packet at x.x.x.x:500(socket=11 ifIndex=4) from Peer y.y.y.y:500 ********      Debug

Ich komme nicht hinter den Fehler, zumal ein anderer Tunnel einwandfrei läuft. Dieser läuft zwischen meiner und der "Test Watchguard"

Spoiler: Bild

//edit stoney: Spoilerinhalt in CodeTag gesetzt

 

[PeterPawn]

Das korrekte Schlüsselwort für die Verwendung eines Domain-Namens zur Adressierung des Peers ist bei der FRITZ!Box dann "remotehostname".

Ansonsten kann ich absolut nicht erkennen, daß/ob Du irgendwelche Proposals angepaßt hast oder nicht ... suche mal nach "ipsec.cfg" im Kontext einer FRITZ!Box mit VPN und passe die WG-Konfiguration so an, daß da etwas verwendet wird, was man auch als Verschlüsselung ansehen kann. Das zuvor zu sehende DES-MD5 verdient diese Bezeichnung schon seit mehreren Jahren nicht mehr wirklich - und dann solltest Du nach Änderungen von Einstellungen einfach hingehen und (a) diese Veränderungen penibel auflisten (da steht nur etwas zur "ipaddr" und zur WG-Konfiguration gar nichts) und (b) das Ergebnis dieser Änderungen trotzdem erneut "vorzeigen". Es soll auch schon Fälle gegeben haben, wo jemand eine solche Änderung zwar richtig "beschreibt", sie aber trotzdem falsch umsetzt.

Außerdem ist es schneller zu überblicken (für Hilfswilliige), wenn sie sich nicht erst Deine aktuelle Konfiguration in mehreren Schritten zusammensuchen müssen. Im Gegensatz zu jemandem, der hier nach einer Lösung für sein eigenes Problem sucht, lesen diese Leute in der Regel so einen Thread auch nicht erneut von Beginn an, wenn der Fragende irgendwelche Informationen "ergänzt" - ist imho auch nicht ihre Aufgabe, denn es gibt ja meist mehr als einen Thread, in dem jemand nach Hilfe sucht. Muß man sich dann das Problem (oder auch das geänderte Problem, wenn es sich nach ersten Schritten verlagert hat) erst mühsam zusammenpuzzlen, verliert man schnell die Lust und auch spätere Leser haben es einfacher, wenn sie für jedes Problem die "Ausgangslage" zusammengefaßt sehen und es mit ihrer eigenen vergleichen können.

Ich gebe auch unumwunden zu, daß ich mir hier gar nicht erst die Mühe gemacht habe, das Log-File genauer anzusehen (mir reicht schon das ins Auge stechende "invalid ID information" als Anzeige, daß Du wohl nicht einmal P1 hinbekommst) ... ohne die Kenntnis der verwendeten Konfigurationen kann man ja nicht einschätzen, ob eine Protokollzeile nun "zu erwarten" ist oder nicht. Und ehe ich es vergesse ... dazu gehört auch noch die "Auskunft" (und zwar nachvollziehbar, auch wenn kein Mensch hier die genaue IP-Adresse wissen will), wie die Internet-Anbindung jeweils aussieht - in der WG-Konfiguration in den Bilder in #1 ist etwas von NAT-T zu sehen, im Protokoll finde ich nichts.

Daß eine 1:1-Kopie einer anderen VPN-Konfiguration eher nicht funktioniert, überrascht mich weniger (und vermutlich auch viele andere nicht, die sich mit dem Thema wirklich beschäftigen) - man sollte/muß schon verstehen, was man da konfiguriert und das erfordert ggf. eine "Einarbeitung" in dieses Thema, für die man Zeit aufbringen und einkalkulieren sollte, wenn man es selbst machen will. Ansonsten sollte man die Finger davon lassen und jemanden beauftragen, der sich damit auskennt.