IPSec Firewall-Regeln
-
87.79.95.169 87.79.88.248 ESP 0835759a 3des-cbc hmac-md5 175596 B
87.79.95.169 87.79.88.248 ESP 03a2d2ce 3des-cbc hmac-md5 1977696 B
87.79.95.169 87.79.88.248 ESP 081c768c 3des-cbc hmac-md5 0 BJa, das Log sagt bei einer Verbindung 0 …. aber ich denke das kommt daher, dass die pfSense gar nichts durch den Tunnel schickt.
Von der Konsole der Fortigate kann ich die interne IP der pfSense pingen - andersrum läuft der Traceroute der pfSense direkt übers Internetgateway raus ....
Ich versteh das nicht ....
Regeln angepasst wie angesagt, überflüssige rausgenommen ... selbe Effekt....
-
Ach so … sorry !
=> Nur ein Gateway, zum Internet.
=> Keine manuellen Routen eingetragen.Der Tunnel steht, wird zumindest grün angezeigt - teilweise werden Daten übertragen, nur nicht die, welche von der pfSense Seite initiiert werden.
Ping in die eine Richtung ok (Fortigate => pfSense)
in die andere Richtung ... nicht möglich. -
sind zwar keine Screenshots aber okay man sieht ja hier schon da sind zu viele Einträge.
Normal sollten dann nur zwei sein einmal hin einmal zurück.
Da scheint noch was im IPSEC nicht zu stimmen.
Prüfe nochmal alle Einstellungen auf beiden Seiten und starte auf beiden Seiten die IPSEC Dienste neu.Ich vermute mal die PfSense will die Daten in einen Tunnel schicken den es wohl nicht mehr gibt. Warum auch immer werden hier mehr Policys angelegt als es sein sollten
vielleicht eine Doppelter Phase 2 Eintrag? Sollte nur einen geben auf jeder Seite
-
Ich verstehe, nein, ist nur eine Phase 2.
Werde ich die beiden mal komplett durchstarten und dann nochmal schauen.
Screenshots sind anstrengend ;-) Teamviewer ist ne Alternative!
-
Ok, also, Neustart auf beiden Seiten bringt nix.
Kann es ggfs. mit dem "Manual Outbound NAT" zu tun haben?
Hab gerade gesehen, dass der Ex-Admin die Automatik abgeschaltet hat,
Firewall => NAT => Outbound. Nach der Doku, irgendwas wegen eines VoIP Servers bei dem die SIP-Anmeldung nicht funktionierte …Wobei dann würde der Tunnel ja gar nicht erst aufgebaut werden .... wenn diese Regeln nicht stimmen würden, oder?
-
das könnte schon was damit zu tun haben wenn das zu "großzügig" definiert ist kann es da schon überschneidungen geben.
wie sehen die Regeln denn aus?
-
Grüße,
es ist alles schick, bis auf das Routing …. und diese Meldung im Log:
racoon: INFO: Update the generated policy : 192.168.xx.0/24[0] 192.168.xx.0/24[0] proto=any dir=in
Und diese Policy wird offenbar nicht aktualisiert und ich hab keine Ahnung warum …. ?
-
da ich mich mit der Gegenstelle leider nicht wirklich auskenne wüsste ich an der Stelle leider nicht mehr wo man noch ansetzen sollte.
Scheint ja alles zu passen bis auf das eine policy wohl doppelt ist.
Könntest unter IPSEC Advanced Einstellungen noch versuchen den Hacken "Prefer older IPsec SAs" zu setzen bzw. zu entfernen und dann den IPSEC Dienst neustarten.
Vielleicht klappt es wenn du damit etwas rumspielst.Ansonsten weiß ich aktuell leider auch nichts mehr.
-
Guten Morgen und danke flix,
- zumindest für den Versuch -
die Fortigate auf der anderen Seite arbeitet in der selben Konfig wie sie für die anderen aufgebauten VPNs auch arbeitet …
nur diese Lady hat kein Interesse mit anderen....Hier gibt es doch sicher noch andere die das Zauberwerk einer IPSec Verbindung zu einem anderen System aufgebaut haben.
- Was passiert, wenn ihr einen Traceroute ins andere Netz macht?
- Wird das andere Netz in den Routen dargestellt?
- Welche Firewall-Regeln sind für das IPSec gesetzt?
Die Fragen hören sich vllt grad was einfältig an … nur bin ich der festen Überzeugung das alles richtig ist und ich vllt. "nur" falsch denke.
Danke.
-
Update: Key Lifetime für Phase 1 auf 86400 gesetzt, Phase 2 auf 3600 - Ping vom externen Netz, über IPSec ins interne Netz …. OK. Ping bekommt Antwort.
Andersrum vom internen Netz ins RemoteNetz übers IPSec ... negativ .... weiterhin werden die Pakete ins Internet und nicht in den Tunnel geschickt.
<seufz>.... snbtch !!</seufz>