Verbindungen über IPsec werden geblockt Fehler TCP: / TCP:PA



  • Hallo,

    ich habe am Wochenende unsere alte Jnuper Netscreen Firewall ausgemustert und eine pfsense installiert.

    Standort 1 (192.168.0.0/24) ist mit Standort 2 (192.168.2.0/24) über einen IPsec Tunel verbunden.
    Auf der Seite Standort 2 läuft noch eine alte Juniper (kann nur Stück für Stück tauschen).

    Leider habe ich noch ein Probleme mit Verbindungen (SMB, Mail,…) über den IPsec Tunnel.
    Die Anwender können z.B: per SMB auf ein Laufwerk zugreifen, nach Zeit X geht das nicht mehr.
    Auch Outlook geht öfter nicht.

    Folgende Meldung habe ich gefunden im Log:

    Mar 8 10:11:07 IPsec 192.168.2.120         192.168.0.200         TCP:
    Mar 8 10:11:07 IPsec 192.168.2.120:59692 192.168.0.200:88 TCP:PA
    Mar 8 10:11:07 IPsec 192.168.2.120         192.168.0.200         TCP:
    Mar 8 10:11:07 IPsec 192.168.2.120:59692 192.168.0.200:88 TCP:PA
    Mar 8 10:11:06 IPsec 192.168.2.120         192.168.0.200    TCP:
    Mar 8 10:11:06 IPsec 192.168.2.120:59692 192.168.0.200:88 TCP:PA

    Ich nutze kein a-syncrones Routing, habe auch keine Backup Leitung etc.

    Was muss ich einstellen, dass er die Verbindunge nicht blockt?

    Wenn ich Unter Firewall --> NAT --> Outbound ein NAT für IPsec mit any-any einstelle geht es.
    Ich finde aber in keiner Anleitung zum pfSense IPsec dass diese NAT Regel notwendig ist.

    Vielleicht liegt es auch an der alten Juniper?

    Danke.

    VG
    HilFi


  • Moderator

    Bist du dir denn siceher, dass diese Meldungen überhaupt mit dem Problem in Bezug stehen? Das was du da kopiert hast ist TCP Port 88, das wäre evtl. Kerberos. Wenn du aber eine Any Any Regel hast (die alles erlaubt) gibt es keinen Grund, warum das plötzlich nicht mehr gehen sollte. Entweder es läuft oder nicht (von Filtersicht betrachtet). Aber eine zeitliche Geschichte wäre seltsam und würde ich eher nachsehen, ob ggf. die Phase 2 vom IPsec plötzlich weg ist oder schlapp macht. Mal zum Test die Phase neu aufbauen lassen und schauen obs daran liegt. Wenn ja muss man da mal reinschauen.

    Ein NAT wird auch im Normalfall nicht gebraucht. Wir hatten auch lange ein IPsec Tunnel mit einer alten Netscreen und da wurde nichts benötigt. Ich würde aber ggf. drüber nachdenken, ob es nicht Sinn macht, die andere Seite schnell auszutauschen und den ganzen Tunnel ggf. durch OpenVPN zu ersetzen… war bei uns meistens schmerzfreier.

    Gruß



  • Moin,

    Vielen Dank für die Antwort.

    Hier ein andere Bps für SMB.:

    Mar 8 10:59:16 IPsec 192.168.2.120         192.168.0.200 TCP:
    Mar 8 10:59:16 IPsec 192.168.2.120:60251 192.168.0.200:445 TCP:A
    Mar 8 10:59:15 IPsec 192.168.2.120         192.168.0.200 TCP:
    Mar 8 10:59:15 IPsec 192.168.2.120:60251 192.168.0.200:445 TCP:A

    Du hast Recht, es muss in keinem Zusammenhang stehen.
    Bin halt nur im Log darüber gestolpert.

    Kann es in der Phase 2 mit der Lifetime zusammenhängen?


  • Moderator

    Im Normalfall passieren solche Blocks nur, wenn Verbindungen abreißen und dann Pakete außerhalb des ursprünglichen States zustande kommen. Das würde in diesem Fall ggf. für ein Zusammenbrechen der Phase sprechen. Sind denn alle Parameter auf beiden Seiten wirklich identisch gesetzt?



  • jetzt gerade z.B. kann ich die Firewall am Standort 192.168.2.1 per ping erreichen, komme aber nicht auf der Web-Interface.
    Tunnel steht. Wenn ich aber den Tunnel trenne und neu aufbaue, geht auch die Webseite.

    Prüfe ich gleich mal.
    Ich kann an der Juniper leider nicht viel einstellen beim VPN.


  • Moderator

    Einstellen nicht, aber ggf. nachsehen, was deren Defaults sind. Aber das hört sich schon ein wenig so an, als würde die Phase da nicht sauber bestehen bleiben



  • Habe jetzt alles abgeglichen, finde im Log aber immer noch die TCP Blocks.
    Die Meldungen kommen auch nur zum LAN 192.168.2.0/24

    die anderen zwei angebundenen Standorte finde ich nicht im Log.



  • am Tunnel kann es eigentlich nicht liegen.

    Ich lasse ein ping 192.168.2.1 -t laufen, alles ohne Unterbrechungen.

    Zur selben Zeit versuche ich von 192.168.0.200 auf WEB-Interface von 192.168.2.1 zuzugreifen.
    Ich sehe im Browser auch, dass er im Browser Tab schon "Login" stehen hat, die Description der Startseite der Firewall.
    Dann "rödelt" er ewig und es passiert nichts.

    Im Log der pfSense finde ich zu dem Zeitpunkt:

    Mar 8 12:54:23 IPsec 192.168.2.1 192.168.0.200         TCP:
    Mar 8 12:54:23 IPsec 192.168.2.1 192.168.0.200         TCP:
    Mar 8 12:54:23 IPsec 192.168.2.1:80 192.168.0.200:25307 TCP:A

    ???

    Bin am verzweifeln…


  • Moderator

    Bitte nicht ICMP mit TCP/UDP gleichsetzen. Andere Protokolle, andere Regeln. Nur weil ein Ping geht, muss der Rest noch lange nicht sauber funktionieren. Das bewahrheitet sich leider viel zu oft. Das "Problem" mit der UI Seite kann aber auch ein ganz anderes sein. Anderer Browser oder derlei, ich würde an der Stelle lieber mit was anderem Testen.



  • IE und Firefox getestet.
    Mit Cache leeren etc.

    Wie geschrieben, mit Jnuiper zu Juniper ging ja alles.



  • Hallo,

    ich bekomme auch vom Drucker im LAN 192.168.2.0/24 mit der IP 192.168.2.192 keine Mails zum internen Mailserver.

    Er blockt: Mar 8 16:38:05 IPsec 192.168.2.192:60619 192.168.0.200:25 TCP:A

    Kann ich irgendwie das blocken der TCP:A etc. für IPsec ausschalten?


  • Moderator

    Nein, das sind ACK Pakete. Das spricht dafür, dass du ggf. irgendwo einen Loop oder asynchrones Routing hast… denn ACKs werden nur dann verworfen, wenn die Sense keinen SYN State vorher dazu findet, ansonsten würde das Paket dank Stateful Inspection einfach durchgelassen werden. Es macht also keinen Sinn "A" Pakete durchzulassen, wenn das Problem ein anderes zu sein scheint (und sie Standard Regeln immer auf das Syn Paket beziehen - Flags S/SA(FR)).

    Wenn die geblockt werden müssten man sehen "warum" - laufen die irgendwie anders als sie sollen - oder wie sehen deine Regeln für IPSec überhaupt aus? Irgendwie bezweifle ich, dass die Blocks hier die Ursache sind.



  • IPSec Rule ist any any.

    Denke werde mal die Switche prüfen lassen.
    Bin ja nicht Vor-Ort.

    Laut dem Log, auf welcher Seite würdest du suchen?

    Auf 192.168.2.0 oder 192.168.0.0?

    Kann ja eigentlich nur auf der 3er Seite sein, da die anderen Netze den Fehler nicht haben.
    Wird morgen gleich geprüft.

    Das ICMP geht ist klar, ist ja UDP und damit stateless.



  • Moin moin,

    ich habe heute folgendes gefunden:

    Mar 9 08:48:52 ► IPsec 192.168.0.200:14941 192.168.2.1:80 TCP:FA

    Was bedeutet das Zeichen "►" vor IPsec?



  • Moin.

    Problem gelöst!

    Ich war in der Niederlassung und habe die alte Juniper Firewall gegen eine neue pfSense getauscht :)

    Jetzt geht alles.

    Selbst wenn ich nur die Juniper am Netz und das VPN zur anderen pfSense aufgebaut hatte, sah es nach einem Loop aus.
    Ich gehe davon aus, dass die Juniper nach über 10 Jahren nicht mehr so recht wollte.

    Danke für die Unterstützung!


  • Moderator

    Super, danke für die Rückmeldung!