gelöst Site 2 Site VPN Zyxel - FritzBox immer wieder Ausfälle
Hallo,
habe nach der Anleitung von https://www.administrator.de/forum/zywall-usg-20-fritzbox-wlan-7360-ipse ... erfolgreich ein S2S-VPN zwischen einer USG60W und meiner Fritte 7490 eingerichtet.
Aber es gibt noch größere Probleme.
1. VPN wird nur aufgebaut, wenn ich auf der Zyxel - VPN auf Verbinden klicke. Ein Ping in das Netzwerksegment hinter dem Tunnel reicht nicht aus.
2. Von seitens der Fritte wird das VPN nicht aufgebaut, immer nur wenn es vom Zyxel kommt.
3. Trotz eines "Nailed-Up" Tunnels bricht die Verbindung immer mal wieder zusammen für 20-30 Sekunden, danach geht es wieder.
Mein Netz: 192.168.200.0/24 hinter der Fritte mit Dyndns
Gegenseite 192.168.0.0/24 hinter der Zyxel mit statischer Adresse, dennoch mal ein Dyndns Account verbunden.
Hier die Config der Fritte:
Seitens der USG60W sind folgende Einstellungen getroffen:
Dauerping von beiden Seiten aus ins Internet ohne Ausfälle. Provider und ähnliches kann ich ausschliessen.
Es taucht auch nix im Log der USG60W auf..... Auszüge kann ich bei Bedarf gerne nachreichen.
Grüße, Henere
habe nach der Anleitung von https://www.administrator.de/forum/zywall-usg-20-fritzbox-wlan-7360-ipse ... erfolgreich ein S2S-VPN zwischen einer USG60W und meiner Fritte 7490 eingerichtet.
Aber es gibt noch größere Probleme.
1. VPN wird nur aufgebaut, wenn ich auf der Zyxel - VPN auf Verbinden klicke. Ein Ping in das Netzwerksegment hinter dem Tunnel reicht nicht aus.
2. Von seitens der Fritte wird das VPN nicht aufgebaut, immer nur wenn es vom Zyxel kommt.
3. Trotz eines "Nailed-Up" Tunnels bricht die Verbindung immer mal wieder zusammen für 20-30 Sekunden, danach geht es wieder.
Mein Netz: 192.168.200.0/24 hinter der Fritte mit Dyndns
Gegenseite 192.168.0.0/24 hinter der Zyxel mit statischer Adresse, dennoch mal ein Dyndns Account verbunden.
Hier die Config der Fritte:
01.
vpncfg { 02.
connections { 03.
enabled = yes; 04.
conn_type = conntype_lan; 05.
name = "XXX.XXX.XXX.XXX"; 06.
always_renew = no; 07.
reject_not_encrypted = no; 08.
dont_filter_netbios = yes; 09.
localip = 0.0.0.0; 10.
local_virtualip = 0.0.0.0; 11.
remoteip = 156.67.X.X; 12.
remote_virtualip = 0.0.0.0; 13.
localid { 14.
fqdn = "XXX.XXX.XXX"; 15.
} 16.
remoteid { 17.
ipaddr = 156.67.X.X; 18.
} 19.
mode = phase1_mode_aggressive; 20.
phase1ss = "all/all/all"; 21.
keytype = connkeytype_pre_shared; 22.
key = "XXXXXXXXX"; 23.
cert_do_server_auth = no; 24.
use_nat_t = no; 25.
use_xauth = no; 26.
use_cfgmode = no; 27.
phase2localid { 28.
ipnet { 29.
ipaddr = 192.168.200.0; 30.
mask = 255.255.255.0; 31.
} 32.
} 33.
phase2remoteid { 34.
ipnet { 35.
ipaddr = 192.168.0.0; 36.
mask = 255.255.255.0; 37.
} 38.
} 39.
phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs"; 40.
accesslist = "permit ip any 192.168.0.0 255.255.255.0"; 41.
} 42.
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 43.
"udp 0.0.0.0:4500 0.0.0.0:4500"; 44.
} 45.
46.
47.
// EOFDauerping von beiden Seiten aus ins Internet ohne Ausfälle. Provider und ähnliches kann ich ausschliessen.
Es taucht auch nix im Log der USG60W auf..... Auszüge kann ich bei Bedarf gerne nachreichen.
Grüße, Henere
22 Antworten
- LÖSUNG 135185 schreibt am 14.01.2018 um 10:03:42 Uhr
- LÖSUNG aqui schreibt am 14.01.2018 um 11:38:10 Uhr
- LÖSUNG sk schreibt am 14.01.2018 um 13:03:24 Uhr
- LÖSUNG Henere schreibt am 14.01.2018 um 13:43:12 Uhr
- LÖSUNG the-buccaneer schreibt am 14.01.2018 um 14:03:05 Uhr
- LÖSUNG Henere schreibt am 14.01.2018 um 14:15:47 Uhr
- LÖSUNG the-buccaneer schreibt am 14.01.2018 um 14:33:12 Uhr
- LÖSUNG aqui schreibt am 14.01.2018 um 16:01:14 Uhr
- LÖSUNG Henere schreibt am 14.01.2018 um 18:32:07 Uhr
- LÖSUNG sk schreibt am 14.01.2018 um 19:11:12 Uhr
- LÖSUNG Henere schreibt am 14.01.2018 um 19:14:59 Uhr
- LÖSUNG Henere schreibt am 15.01.2018 um 00:43:13 Uhr
- LÖSUNG the-buccaneer schreibt am 15.01.2018 um 07:34:33 Uhr
- LÖSUNG Henere schreibt am 15.01.2018 um 16:46:47 Uhr
- LÖSUNG sk schreibt am 15.01.2018 um 17:31:21 Uhr
- LÖSUNG Henere schreibt am 15.01.2018 um 17:46:53 Uhr
- LÖSUNG Henere schreibt am 16.01.2018 um 00:34:52 Uhr
- LÖSUNG sk schreibt am 16.01.2018 um 09:42:50 Uhr
- LÖSUNG Henere schreibt am 16.01.2018 um 00:34:52 Uhr
- LÖSUNG Henere schreibt am 15.01.2018 um 17:46:53 Uhr
- LÖSUNG sk schreibt am 15.01.2018 um 17:31:21 Uhr
- LÖSUNG Henere schreibt am 15.01.2018 um 16:46:47 Uhr
- LÖSUNG the-buccaneer schreibt am 15.01.2018 um 07:34:33 Uhr
- LÖSUNG Henere schreibt am 15.01.2018 um 00:43:13 Uhr
- LÖSUNG Henere schreibt am 14.01.2018 um 19:14:59 Uhr
- LÖSUNG sk schreibt am 14.01.2018 um 19:11:12 Uhr
- LÖSUNG Henere schreibt am 14.01.2018 um 18:32:07 Uhr
- LÖSUNG Henere schreibt am 14.01.2018 um 18:35:37 Uhr
- LÖSUNG aqui schreibt am 14.01.2018 um 16:01:14 Uhr
- LÖSUNG the-buccaneer schreibt am 14.01.2018 um 14:33:12 Uhr
- LÖSUNG Henere schreibt am 14.01.2018 um 14:15:47 Uhr
- LÖSUNG the-buccaneer schreibt am 14.01.2018 um 14:03:05 Uhr
- LÖSUNG Henere schreibt am 14.01.2018 um 13:35:26 Uhr
- LÖSUNG aqui schreibt am 14.01.2018 um 11:38:10 Uhr
- LÖSUNG ChriBo schreibt am 14.01.2018 um 13:26:52 Uhr
- LÖSUNG Henere schreibt am 14.01.2018 um 13:52:39 Uhr
LÖSUNG 14.01.2018, aktualisiert um 10:06 Uhr
Schau nochmal ganz genau auf die SA Lifetimes, die sind bei dir viel zu lang! Die müssen mit der Fritte matchen sonst kommt es nämlich genau zu diesem Abbrüchen wenn mitten drin die SAs absaufen.
LÖSUNG 14.01.2018, aktualisiert um 11:38 Uhr
Das ist richtig ! Die Cipher Suite Timer müssen zwingend auf beiden Seiten identisch sein. Das ist immer der typische Fehler wenn es in heterogenen Umgebungen zu solchen Abbrüchen kommt.
Zu Punkt 2 wäre noch interessant was dann am Zyxel im Log steht !!
Leider fehlen hier wie immer die Log Auszüge so das man hier nur frei raten kann ohne zielführende Informationen
Vermutlich stimmt hier auch etwas in den Credentials nicht ?!
Grundlagen zur IPsec VPN Kopplung findet man sonst auch hier:
https://www.administrator.de/wissen/ipsec-vpn-praxis-standort-kopplung-c ...
Zu Punkt 2 wäre noch interessant was dann am Zyxel im Log steht !!
Leider fehlen hier wie immer die Log Auszüge so das man hier nur frei raten kann ohne zielführende Informationen
Vermutlich stimmt hier auch etwas in den Credentials nicht ?!
Grundlagen zur IPsec VPN Kopplung findet man sonst auch hier:
https://www.administrator.de/wissen/ipsec-vpn-praxis-standort-kopplung-c ...
LÖSUNG 14.01.2018 um 13:03 Uhr
Die FB im Aggressivemode. Die ZW im Main-Mode. Da sollte der Tunnel eigentlich gar nicht zustande kommen...
LÖSUNG 14.01.2018 um 13:26 Uhr
Hi,
das du überhaupt ein VPN aufbauen kannst verwundert mich.
Wie schon von Anderen festgestellt wurde:
Negotiation Mode ist unterschiedlich
die SA Lifetime Phase Einstellung für Phase 1 und 2 sieht nicht richtig aus.
Üblich ist häufig 28800(8h) und 3600 (1h)
-
Ebenso scheint das "Application Scenario" verkehrt zu sein: Es muß Site-to-Site with Dynamic Peer sein
Gruß
CH
das du überhaupt ein VPN aufbauen kannst verwundert mich.
Wie schon von Anderen festgestellt wurde:
Negotiation Mode ist unterschiedlich
die SA Lifetime Phase Einstellung für Phase 1 und 2 sieht nicht richtig aus.
Üblich ist häufig 28800(8h) und 3600 (1h)
-
Ebenso scheint das "Application Scenario" verkehrt zu sein: Es muß Site-to-Site with Dynamic Peer sein
Gruß
CH
LÖSUNG 14.01.2018 um 13:35 Uhr
Das ist der default-Wert der USG. Allerdings sehe ich in der CFG für die Fritte keien Angabe über die Lifetime, oder übersehe ich was ?
Welchen Wert sollte man hier nehmen ?
Welchen Wert sollte man hier nehmen ?
LÖSUNG 14.01.2018 um 13:43 Uhr
Im Log taucht das hier auf:
Peer not reachable
The cookie Pair is
Send [Hash]NOTIFY:R_U_THERE] [count2]
ISAKMP SA [Gatewayname] is disconnected.
TUNNEL[Name] Sending IKE Request
SEND MAIN MODE REQUEST (meine IP)
Kann man das Log einer Zyxel eigentlich irgendwie exportieren ? Ausser es per Mail zu versenden ?
Das Peer not reachable irritiert mich. Ping von beiden Seiten auf www.avm.de ist die ganze Nacht gelaufen, ohne ein Packet Loss.
Ping von Netz a nach b hat bis zu 10% Packet Loss. Immer mal wieder ein paar Sekunden weg, danach geht es wieder.
Henner
Peer not reachable
The cookie Pair is
Send [Hash]NOTIFY:R_U_THERE] [count2]
ISAKMP SA [Gatewayname] is disconnected.
TUNNEL[Name] Sending IKE Request
SEND MAIN MODE REQUEST (meine IP)
Kann man das Log einer Zyxel eigentlich irgendwie exportieren ? Ausser es per Mail zu versenden ?
Das Peer not reachable irritiert mich. Ping von beiden Seiten auf www.avm.de ist die ganze Nacht gelaufen, ohne ein Packet Loss.
Ping von Netz a nach b hat bis zu 10% Packet Loss. Immer mal wieder ein paar Sekunden weg, danach geht es wieder.
Henner
LÖSUNG 14.01.2018 um 13:52 Uhr
Zitat von ChriBo:
Hi,
das du überhaupt ein VPN aufbauen kannst verwundert mich.
Wie schon von Anderen festgestellt wurde:
Negotiation Mode ist unterschiedlich
die SA Lifetime Phase Einstellung für Phase 1 und 2 sieht nicht richtig aus.
Üblich ist häufig 28800(8h) und 3600 (1h)
-
Ebenso scheint das "Application Scenario" verkehrt zu sein: Es muß Site-to-Site with Dynamic Peer sein
Gruß
CH
Hi,
das du überhaupt ein VPN aufbauen kannst verwundert mich.
Wie schon von Anderen festgestellt wurde:
Negotiation Mode ist unterschiedlich
die SA Lifetime Phase Einstellung für Phase 1 und 2 sieht nicht richtig aus.
Üblich ist häufig 28800(8h) und 3600 (1h)
-
Ebenso scheint das "Application Scenario" verkehrt zu sein: Es muß Site-to-Site with Dynamic Peer sein
Gruß
CH
Wenn ich auf Dynamic Peer umstelle, kann ich das VPN-Gateway nicht mehr auswählen.
Wenn ich dann im VPN-Gateway von statisch auf dynamisch umstelle, bekomme ich beim Klick auf OK den Text hier serviert:
CLI Number: 3
Warning Number: 16015
Warning Message: 'Crypto map scenario is invalid!'
Der Tunnel muss ja von beiden Seiten aufgebaut werden können, wenn ich es auf dynamic umstelle, dann kann die USG die Verbindung nicht aufbauen, weil sie ja gar nciht weiß, wohin... oder Denkfehler ?
Wo kann ich denn die Lifetime für Phase1 einstellen ? In der CFG der Fritte taucht Lifetime nicht auf, in der USG sehe ich es nur für Phase 2. P2 haber ich jetzt auf 3600 umgestellt.
LÖSUNG 14.01.2018 um 14:03 Uhr
Moin!
Nimm mal eine Lifetime von 3600s für beide Phasen. Das ist das default der FB.
(Es gibt seit einiger Zeit andere Einstellungen mit mehreren Stunden, die könntest du später ja noch anpassen) siehe z.b. hier: https://blog.webernetz.net/fritzos-ab-06-23-ipsec-p2-proposals-erweitert ...
Dann auf "aggressive" und "Dynamic Peer" umstellen .
"always_renew" in der FB auf "yes" (Damit stellt sie die Verbindung nach Ablauf wieder her)
Ich habe besere Erfahrungen, wenn nur die FB die Verbindung initiiert, daher mal die Zyxel auf Responder umstellen.
Kann die Zyxel kein AES-256?
Gruß
Buc
Nimm mal eine Lifetime von 3600s für beide Phasen. Das ist das default der FB.
(Es gibt seit einiger Zeit andere Einstellungen mit mehreren Stunden, die könntest du später ja noch anpassen) siehe z.b. hier: https://blog.webernetz.net/fritzos-ab-06-23-ipsec-p2-proposals-erweitert ...
Dann auf "aggressive" und "Dynamic Peer" umstellen .
"always_renew" in der FB auf "yes" (Damit stellt sie die Verbindung nach Ablauf wieder her)
Ich habe besere Erfahrungen, wenn nur die FB die Verbindung initiiert, daher mal die Zyxel auf Responder umstellen.
Kann die Zyxel kein AES-256?
Gruß
Buc
LÖSUNG 14.01.2018 um 14:15 Uhr
Servuis,
Nimm mal eine Lifetime von 3600s für beide Phasen. Das ist das default der FB.
Wo stelle ich das für beide Phasen ein ? In der USG finde ich nur die Einstellung für Phase 2
(Es gibt seit einiger Zeit andere Einstellungen mit mehreren Stunden, die könntest du später ja noch anpassen) siehe z.b. hier: https://blog.webernetz.net/fritzos-ab-06-23-ipsec-p2-proposals-erweitert ...
Dann auf "aggressive" und "Dynamic Peer" umstellen .
Wenn ich das mache, wie kann dann die USG den Tunnel zur Fritte herstellen ? Ich habe dann keine Möglichkeit mehr, einen FQDN einzugeben.
"always_renew" in der FB auf "yes" (Damit stellt sie die Verbindung nach Ablauf wieder her)
Erledigt
Ich habe besere Erfahrungen, wenn nur die FB die Verbindung initiiert, daher mal die Zyxel auf Responder umstellen.
Kann die Zyxel kein AES-256?
Kann die Zyxel kein AES-256?
Hab ich jetzt von 3DES auf AES256 umgestellt.
Gruß
Buc
Buc
Grüße, Henere
LÖSUNG 14.01.2018 um 14:33 Uhr
Die FB nimmt 3600s automatisch.
In der Zyxel kann ich auf deinem 2. Bild erkennen, dass man da die Phase 1 Lifetime und den Negotiation Mode einstellen kann.
Es reicht im Zweifel, wenn die FB den Tunnel herstellt. Die Fritte reagiert nicht immer zuverlässig auf Proposals der Gegenseite.
Buc
In der Zyxel kann ich auf deinem 2. Bild erkennen, dass man da die Phase 1 Lifetime und den Negotiation Mode einstellen kann.
Es reicht im Zweifel, wenn die FB den Tunnel herstellt. Die Fritte reagiert nicht immer zuverlässig auf Proposals der Gegenseite.
Buc
LÖSUNG 14.01.2018, aktualisiert um 16:02 Uhr
Das Peer not reachable irritiert mich.
Kollege sk hat hier absolut Recht. Eine Seite im Agressive Mode und eine im Main Mode kann niemals klappen bei IPsec !In einem heterogenen Umfeld (unterschiedliche Hersteller) nimmt man beidseitig IMMER den Aggressive Mode !
Also damit mal probieren, Timer anpassen das die gleich sind und dann nochmals die Logs posten von beiden Maschinen beim Verbindungsaufbau !
Vermutlich löst das eh schon das Problem.
LÖSUNG 14.01.2018 um 18:32 Uhr
Das irritierende an der ganzen Geschichte..... der Tunnelaufbau scheint ja zu klappen. Trotz Main und Aggressive Mode.
Wie bekomme ich das Log aus der USG exportiert ?
Das einzige was ich sehe, ist die Möglichkeit das per Mail zu schicken. Das macht sie aber nicht.
Testmail und den Daily Report bekomme ich raus, beim Log bekomme ich immer nen Fehler:
Verstehe ich noch nicht, der next-hop-mailer ist eingetragen und der mailer (postfix) hat die ext IP in mynetworks. Da blockiert nix.
Auf der Fritte müsste ich dann halt nen Paketmitschnitt machen, logging ist da nicht wirklich möglich.
Wie bekomme ich das Log aus der USG exportiert ?
Das einzige was ich sehe, ist die Möglichkeit das per Mail zu schicken. Das macht sie aber nicht.
Testmail und den Daily Report bekomme ich raus, beim Log bekomme ich immer nen Fehler:
01.
Email log now: => 02.
CLI Numer 0 03.
Error Numer: -23008 04.
Error Message: "Both mail servers are not ready"Auf der Fritte müsste ich dann halt nen Paketmitschnitt machen, logging ist da nicht wirklich möglich.
LÖSUNG 14.01.2018 um 18:35 Uhr
Zitat von the-buccaneer:
Die FB nimmt 3600s automatisch.
In der Zyxel kann ich auf deinem 2. Bild erkennen, dass man da die Phase 1 Lifetime und den Negotiation Mode einstellen kann.
Es reicht im Zweifel, wenn die FB den Tunnel herstellt. Die Fritte reagiert nicht immer zuverlässig auf Proposals der Gegenseite.
Buc
Die FB nimmt 3600s automatisch.
In der Zyxel kann ich auf deinem 2. Bild erkennen, dass man da die Phase 1 Lifetime und den Negotiation Mode einstellen kann.
Es reicht im Zweifel, wenn die FB den Tunnel herstellt. Die Fritte reagiert nicht immer zuverlässig auf Proposals der Gegenseite.
Buc
Zeit steht jetzt auf 3600 und auf der USG ist umgestellt auf aggressive. Tunnel läuft. Mal schauen wie lange.
LÖSUNG 14.01.2018 um 19:11 Uhr
Zitat von Henere:
Wie bekomme ich das Log aus der USG exportiert ?
Das einzige was ich sehe, ist die Möglichkeit das per Mail zu schicken. Das macht sie aber nicht.
Testmail und den Daily Report bekomme ich raus, beim Log bekomme ich immer nen Fehler: ...
Verstehe ich noch nicht, der next-hop-mailer ist eingetragen und der mailer (postfix) hat die ext IP in mynetworks. Da blockiert nix.
Wie bekomme ich das Log aus der USG exportiert ?
Das einzige was ich sehe, ist die Möglichkeit das per Mail zu schicken. Das macht sie aber nicht.
Testmail und den Daily Report bekomme ich raus, beim Log bekomme ich immer nen Fehler: ...
Verstehe ich noch nicht, der next-hop-mailer ist eingetragen und der mailer (postfix) hat die ext IP in mynetworks. Da blockiert nix.
Entweder auf einen USB-Stick oder auf einen Syslog-Server schreiben lassen
Gruß
sk
LÖSUNG 14.01.2018 um 19:14 Uhr
Ist das deren Ernst ? Irgendwie war bei Checkpoint (13 Jahre her) alles einfacher, übersichtlicher, besser strukturiert.
USB muss ich mal jemanden beauftragen da mal was anzustöpseln. Für jetzt noch nen weiteren Server (oder Dienst) hab ich grad nicht den Nerv dazu.
Eh ne sehr geile Idee von Zyxel FW-Logs per Mail verschicken zu können. "Security-Appliance" und dann im Klartext Mails verschicken....
Naja, schaun mer mal. Nach Änderung auf 3600 und beide Seiten im Aggressive-Mode sieht es deutlich stabiler aus.
Ich werde es bis morgen beobachten und berichten.
Danke erstmal bis hierher an alle Beteiligten.
Henere
LÖSUNG 15.01.2018, aktualisiert um 00:52 Uhr
Sehr merkwürdig alles.
Ich habe durch das VPN von A nach B 1% Packetloss beim Dauerping über 2h hinweg. Dennoch kann man sauber arbeiten über das VPN.
Aber im Log der Fritte finde ich das hier:
Laut AVM => IKE-Error 0x2026 "no proposal chosen"
Das geht ewig so weiter.
Aktuelle CFG der Fritte:
Log von der USG lasse ich morgen auf USB ziehen, dann kann ich es posten.
Ich habe durch das VPN von A nach B 1% Packetloss beim Dauerping über 2h hinweg. Dennoch kann man sauber arbeiten über das VPN.
Aber im Log der Fritte finde ich das hier:
01.
14.01.18 23:49:57 VPN-Verbindung zu XXXXXX.spdns.de wurde erfolgreich hergestellt. 02.
14.01.18 23:49:52 VPN-Fehler: XXXXXX.spdns.de, IKE-Error 0x2026 03.
14.01.18 23:48:27 VPN-Verbindung zu XXXXXX.spdns.de wurde erfolgreich hergestellt. 04.
14.01.18 23:48:27 VPN-Fehler: XXXXXX.spdns.de, IKE-Error 0x2026 05.
14.01.18 23:47:02 VPN-Verbindung zu XXXXXX.spdns.de wurde erfolgreich hergestellt. 06.
14.01.18 23:47:02 VPN-Fehler: XXXXXX.spdns.de, IKE-Error 0x2026 07.
14.01.18 23:45:37 VPN-Verbindung zu XXXXXX.spdns.de wurde erfolgreich hergestellt. 08.
14.01.18 23:45:37 VPN-Fehler: XXXXXX.spdns.de, IKE-Error 0x2026 09.
14.01.18 23:44:13 VPN-Verbindung zu XXXXXX.spdns.de wurde erfolgreich hergestellt. 10.
14.01.18 23:44:13 VPN-Fehler: XXXXXX.spdns.de, IKE-Error 0x2026 11.
14.01.18 23:42:48 VPN-Verbindung zu XXXXXX.spdns.de wurde erfolgreich hergestellt. 12.
14.01.18 23:42:48 VPN-Fehler: XXXXXX.spdns.de, IKE-Error 0x2026 13.
14.01.18 23:41:23 VPN-Verbindung zu XXXXXX.spdns.de wurde erfolgreich hergestellt. 14.
14.01.18 23:41:23 VPN-Fehler: XXXXXX.spdns.de, IKE-Error 0x2026 15.
14.01.18 23:39:58 VPN-Verbindung zu XXXXXX.spdns.de wurde erfolgreich hergestellt. Das geht ewig so weiter.
Aktuelle CFG der Fritte:
01.
vpncfg { 02.
connections { 03.
enabled = yes; 04.
conn_type = conntype_lan; 05.
name = "XXXXXXXX.spdns.de"; 06.
always_renew = yes; 07.
reject_not_encrypted = no; 08.
dont_filter_netbios = yes; 09.
localip = 0.0.0.0; 10.
local_virtualip = 0.0.0.0; 11.
remoteip = 156.67.XXX.XXX; 12.
remote_virtualip = 0.0.0.0; 13.
localid { 14.
fqdn = "XXXXX.spdns.de"; 15.
} 16.
remoteid { 17.
ipaddr = 156.67.XXX.XXX; 18.
} 19.
mode = phase1_mode_aggressive; 20.
phase1ss = "all/all/all"; 21.
keytype = connkeytype_pre_shared; 22.
key = "XXXXXXXXXXXXXX"; 23.
cert_do_server_auth = no; 24.
use_nat_t = no; 25.
use_xauth = no; 26.
use_cfgmode = no; 27.
phase2localid { 28.
ipnet { 29.
ipaddr = 192.168.200.0; 30.
mask = 255.255.255.0; 31.
} 32.
} 33.
phase2remoteid { 34.
ipnet { 35.
ipaddr = 192.168.0.0; 36.
mask = 255.255.255.0; 37.
} 38.
} 39.
phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs"; 40.
accesslist = "permit ip any 192.168.0.0 255.255.255.0"; 41.
} 42.
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 43.
"udp 0.0.0.0:4500 0.0.0.0:4500"; 44.
} 45.
46.
47.
// EOFLog von der USG lasse ich morgen auf USB ziehen, dann kann ich es posten.
LÖSUNG 15.01.2018 um 07:34 Uhr
Moin!
Ist irgendwas in der Phase 2 obwohl das erstmal gut aussieht.
Du hast auf der Zyxel NAT-T gesetzt, auf der FB aber use_nat_t=no.
Setze mal use_nat_t=yes.
Und versuche mal: phase2ss = "esp-all-all/ah-none/comp-all/pfs";
Wie es sein kann, dass die Verbindung steht, aber gleichzeitig "no proposal chosen" ausgegeben wird?
Nicht ganz kongruent.
Die Zyxel mit Dynamic Host geht nicht?
Gruß
Buc
Ist irgendwas in der Phase 2 obwohl das erstmal gut aussieht.
Du hast auf der Zyxel NAT-T gesetzt, auf der FB aber use_nat_t=no.
Setze mal use_nat_t=yes.
Und versuche mal: phase2ss = "esp-all-all/ah-none/comp-all/pfs";
Wie es sein kann, dass die Verbindung steht, aber gleichzeitig "no proposal chosen" ausgegeben wird?
Nicht ganz kongruent.
Die Zyxel mit Dynamic Host geht nicht?
Gruß
Buc
LÖSUNG 15.01.2018, aktualisiert um 16:48 Uhr
Servus,
ist in der Fritten-CFG jetzt drin. Tunnel ist up, Traffic geht durch, aber immer wieder 0x2026 auf der Fritte.
Ich habe das logging der USG jetzt auf USB gestellt. Darüber kann man dann die Files mit einem Browser holen..... Wer bitte lässt sich so einen Schwachsinn einfallen ?
Dass der Tunnel up ist, sehe ich hier am Ping.
Grüße, Henere
01.
nat_t_yes 02.
phase2ss = "esp-all-all/ah-none/comp-all/pfs";Ich habe das logging der USG jetzt auf USB gestellt. Darüber kann man dann die Files mit einem Browser holen..... Wer bitte lässt sich so einen Schwachsinn einfallen ?
01.
Time ,Source ,Destination ,Priority ,Category ,Note ,Source Interface ,Destination Interface ,Protocol ,Message 02.
======================================================================================================================================================================================================================================================================================== 03.
2018-01-15 16:25:42,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0x89db735c3bd6088c / 0x102a551a8d583ebc 04.
2018-01-15 16:25:42,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][NOTIFY:R_U_THERE] 05.
2018-01-15 16:25:55,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0x89db735c3bd6088c / 0x102a551a8d583ebc 06.
2018-01-15 16:25:55,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][NOTIFY:R_U_THERE] 07.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Peer not reachable 08.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0x89db735c3bd6088c / 0x102a551a8d583ebc 09.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][DEL] 10.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0x89db735c3bd6088c / 0x102a551a8d583ebc 11.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][DEL] 12.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0x89db735c3bd6088c / 0x102a551a8d583ebc 13.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][DEL] 14.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0x89db735c3bd6088c / 0x102a551a8d583ebc 15.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , ISAKMP SA [GATEWAYNAME] is disconnected 16.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0x0000000000000000 17.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Tunnel [GATEWAYNAME] Sending IKE request 18.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0x0000000000000000 19.
2018-01-15 16:26:16,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send Aggressive Mode request to [93.207.XXX.XXX] 20.
2018-01-15 16:26:17,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0x0000000000000000 21.
2018-01-15 16:26:17,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[SA][KE][NONCE][ID][VID][VID][VID][VID][VID][VID][VID][VID][VID] 22.
2018-01-15 16:26:17,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xaa5b9c8f351ed5a7 / 0xf6532df896875851 23.
2018-01-15 16:26:17,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Recv:[SA][KE][NONCE][ID][HASH][VID][VID] 24.
2018-01-15 16:26:17,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 25.
2018-01-15 16:26:17,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH] 26.
2018-01-15 16:26:17,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 27.
2018-01-15 16:26:17,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Phase 1 IKE SA process done 28.
2018-01-15 16:26:17,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 29.
2018-01-15 16:26:17,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][SA][NONCE][KE][ID][ID] 30.
2018-01-15 16:26:17,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xaa5b9c8f351ed5a7 / 0xf6532df896875851 31.
2018-01-15 16:26:17,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Recv:[HASH][NOTIFY:INITIAL_CONTACT] 32.
2018-01-15 16:26:18,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xaa5b9c8f351ed5a7 / 0xf6532df896875851 33.
2018-01-15 16:26:18,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Recv:[HASH][SA][NONCE][KE][ID][ID] 34.
2018-01-15 16:26:18,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 35.
2018-01-15 16:26:18,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH] 36.
2018-01-15 16:26:18,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 37.
2018-01-15 16:26:18,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , [Initiator:156.67.XXX.XXX][Responder:93.207.XXX.XXX] 38.
2018-01-15 16:26:18,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 39.
2018-01-15 16:26:18,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , [Policy: ipv4(192.168.0.0-192.168.0.255)-ipv4(192.168.200.0-192.168.200.255)] 40.
2018-01-15 16:26:18,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 41.
2018-01-15 16:26:18,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , [ESP aes-cbc|hmac-sha1-96][SPI 0xff28ca7d|0xebf90592][PFS:DH2][Lifetime 3300] 42.
2018-01-15 16:26:18,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 43.
2018-01-15 16:26:18,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Tunnel [GATEWAYNAME:GATEWAYNAME:0xebf90592] built successfully 44.
2018-01-15 16:26:18,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xaa5b9c8f351ed5a7 / 0xf6532df896875851 45.
2018-01-15 16:26:18,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Recv:[HASH][DEL] 46.
2018-01-15 16:26:18,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xaa5b9c8f351ed5a7 / 0xf6532df896875851 47.
2018-01-15 16:26:18,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Recv:[HASH][DEL] 48.
2018-01-15 16:26:18,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xaa5b9c8f351ed5a7 / 0xf6532df896875851 49.
2018-01-15 16:26:18,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Recv:[HASH][DEL] 50.
2018-01-15 16:26:18,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xaa5b9c8f351ed5a7 / 0xf6532df896875851 51.
2018-01-15 16:26:18,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Recv:[HASH][DEL] 52.
2018-01-15 16:26:48,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 53.
2018-01-15 16:26:48,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][NOTIFY:R_U_THERE] 54.
2018-01-15 16:26:49,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 55.
2018-01-15 16:26:49,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][NOTIFY:R_U_THERE] 56.
2018-01-15 16:26:51,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 57.
2018-01-15 16:26:51,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][NOTIFY:R_U_THERE] 58.
2018-01-15 16:26:54,85.11.23.12:33224 ,156.67.XXX.XXX:23 , notice ,secure-policy ,ACCESS BLOCK , wan1 , ,tcp , Match default rule, DROP 59.
2018-01-15 16:26:54,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 60.
2018-01-15 16:26:54,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][NOTIFY:R_U_THERE] 61.
2018-01-15 16:26:59,185.222.211.41:44546 ,156.67.XXX.XXX:2155 , notice ,secure-policy ,ACCESS BLOCK , wan1 , ,tcp , Match default rule, DROP 62.
2018-01-15 16:26:59,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 63.
2018-01-15 16:26:59,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][NOTIFY:R_U_THERE] 64.
2018-01-15 16:27:07,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 65.
2018-01-15 16:27:07,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][NOTIFY:R_U_THERE] 66.
2018-01-15 16:27:20,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 67.
2018-01-15 16:27:20,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][NOTIFY:R_U_THERE] 68.
2018-01-15 16:27:41,181.214.87.245:44449 ,156.67.XXX.XXX:1054 , notice ,secure-policy ,ACCESS BLOCK , wan1 , ,tcp , Match default rule, DROP 69.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Peer not reachable 70.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 71.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][DEL] 72.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 73.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][DEL] 74.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 75.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][DEL] 76.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xf6532df896875851 / 0xaa5b9c8f351ed5a7 77.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , ISAKMP SA [GATEWAYNAME] is disconnected 78.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xa809f140e4a53403 / 0x0000000000000000 79.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Tunnel [GATEWAYNAME] Sending IKE request 80.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xa809f140e4a53403 / 0x0000000000000000 81.
2018-01-15 16:27:41,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send Aggressive Mode request to [93.207.XXX.XXX] 82.
2018-01-15 16:27:42,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xa809f140e4a53403 / 0x0000000000000000 83.
2018-01-15 16:27:42,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[SA][KE][NONCE][ID][VID][VID][VID][VID][VID][VID][VID][VID][VID] 84.
2018-01-15 16:27:42,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xb837cc503c983799 / 0xa809f140e4a53403 85.
2018-01-15 16:27:42,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Recv:[SA][KE][NONCE][ID][HASH][VID][VID] 86.
2018-01-15 16:27:42,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xa809f140e4a53403 / 0xb837cc503c983799 87.
2018-01-15 16:27:42,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH] 88.
2018-01-15 16:27:42,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xa809f140e4a53403 / 0xb837cc503c983799 89.
2018-01-15 16:27:42,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Phase 1 IKE SA process done 90.
2018-01-15 16:27:42,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xa809f140e4a53403 / 0xb837cc503c983799 91.
2018-01-15 16:27:42,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH][SA][NONCE][KE][ID][ID] 92.
2018-01-15 16:27:42,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xb837cc503c983799 / 0xa809f140e4a53403 93.
2018-01-15 16:27:42,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Recv:[HASH][NOTIFY:INITIAL_CONTACT] 94.
2018-01-15 16:27:43,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xb837cc503c983799 / 0xa809f140e4a53403 95.
2018-01-15 16:27:43,93.207.XXX.XXX:500 ,156.67.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Recv:[HASH][SA][NONCE][KE][ID][ID] 96.
2018-01-15 16:27:43,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xa809f140e4a53403 / 0xb837cc503c983799 97.
2018-01-15 16:27:43,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Send:[HASH] 98.
2018-01-15 16:27:43,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xa809f140e4a53403 / 0xb837cc503c983799 99.
2018-01-15 16:27:43,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , [Initiator:156.67.XXX.XXX][Responder:93.207.XXX.XXX] 100.
2018-01-15 16:27:43,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xa809f140e4a53403 / 0xb837cc503c983799 101.
2018-01-15 16:27:43,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , [Policy: ipv4(192.168.0.0-192.168.0.255)-ipv4(192.168.200.0-192.168.200.255)] 102.
2018-01-15 16:27:43,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xa809f140e4a53403 / 0xb837cc503c983799 103.
2018-01-15 16:27:43,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , [ESP aes-cbc|hmac-sha1-96][SPI 0x447642c9|0x23ae37a3][PFS:DH2][Lifetime 3420] 104.
2018-01-15 16:27:43,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , The cookie pair is : 0xa809f140e4a53403 / 0xb837cc503c983799 105.
2018-01-15 16:27:43,156.67.XXX.XXX:500 ,93.207.XXX.XXX:500 , info ,ike ,IKE_LOG , , , , Tunnel [GATEWAYNAME:GATEWAYNAME:0x23ae37a3] built successfully01.
Ping-Statistik für 192.168.0.10: 02.
Pakete: Gesendet = 795, Empfangen = 783, Verloren = 12 03.
(1% Verlust), 04.
Ca. Zeitangaben in Millisek.: 05.
Minimum = 15ms, Maximum = 372ms, Mittelwert = 17msLÖSUNG 15.01.2018 um 17:31 Uhr
Schalte mal auf der USG das DPD ab!
Gruß
sk
Gruß
sk
LÖSUNG 15.01.2018 um 17:46 Uhr
Seit 17:17 (keine Änderung Fritte oder USG seit dem Post von 16:48 habe ich auf der Fritte keinen 0X2026 mehr ?
Dead Peer Detection in P1 habe ich dennoch im VPG-Gateway-Objekt abgeschaltet.
Schaun mer mal....
Grüße, Henere
LÖSUNG 16.01.2018 um 00:34 Uhr
So gefällt mir das schon besser.
Ping-Statistik für 192.168.0.10:
Pakete: Gesendet = 22311, Empfangen = 22305, Verloren = 6
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 15ms, Maximum = 114ms, Mittelwert = 16ms
Ping-Statistik für 192.168.200.1:
Pakete: Gesendet = 12640, Empfangen = 12640, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 15ms, Maximum = 63ms, Mittelwert = 16ms
Ich denke, das war es jetzt. Keine Fehler mehr im Log zu finden.
Ich danke allen Beteiligten für die kompetente Hilfe !
Grüße, Henere
Ping-Statistik für 192.168.0.10:
Pakete: Gesendet = 22311, Empfangen = 22305, Verloren = 6
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 15ms, Maximum = 114ms, Mittelwert = 16ms
Ping-Statistik für 192.168.200.1:
Pakete: Gesendet = 12640, Empfangen = 12640, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 15ms, Maximum = 63ms, Mittelwert = 16ms
Ich denke, das war es jetzt. Keine Fehler mehr im Log zu finden.
Ich danke allen Beteiligten für die kompetente Hilfe !
Grüße, Henere
LÖSUNG 16.01.2018 um 09:42 Uhr
Gut. Dann folgt jetzt das Hardening.
1) Mainmode statt Aggressivmode
https://m.heise.de/security/artikel/Zu-Schnell-271296.html
2) Nur Crypto- und Hashing-Algos verwenden, die noch als sicher gelten.
Gruß
sk
1) Mainmode statt Aggressivmode
https://m.heise.de/security/artikel/Zu-Schnell-271296.html
2) Nur Crypto- und Hashing-Algos verwenden, die noch als sicher gelten.
Gruß
sk
Ähnliche Inhalte
Neue Wissensbeiträge
Heiß diskutierte Inhalte
