Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Deutsch
    2
    16
    1.4k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H
      hilfi2000
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • JeGrJ
        JeGr LAYER 8 Moderator
        last edited by

        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ß

        Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

        If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

        1 Reply Last reply Reply Quote 0
        • H
          hilfi2000
          last edited by

          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?

          1 Reply Last reply Reply Quote 0
          • JeGrJ
            JeGr LAYER 8 Moderator
            last edited by

            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?

            Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

            1 Reply Last reply Reply Quote 0
            • H
              hilfi2000
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • JeGrJ
                JeGr LAYER 8 Moderator
                last edited by

                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

                Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                1 Reply Last reply Reply Quote 0
                • H
                  hilfi2000
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • H
                    hilfi2000
                    last edited by

                    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…

                    1 Reply Last reply Reply Quote 0
                    • JeGrJ
                      JeGr LAYER 8 Moderator
                      last edited by

                      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.

                      Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                      If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                      1 Reply Last reply Reply Quote 0
                      • H
                        hilfi2000
                        last edited by

                        IE und Firefox getestet.
                        Mit Cache leeren etc.

                        Wie geschrieben, mit Jnuiper zu Juniper ging ja alles.

                        1 Reply Last reply Reply Quote 0
                        • H
                          hilfi2000
                          last edited by

                          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?

                          1 Reply Last reply Reply Quote 0
                          • JeGrJ
                            JeGr LAYER 8 Moderator
                            last edited by

                            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.

                            Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                            If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                            1 Reply Last reply Reply Quote 0
                            • H
                              hilfi2000
                              last edited by

                              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.

                              1 Reply Last reply Reply Quote 0
                              • H
                                hilfi2000
                                last edited by

                                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?

                                1 Reply Last reply Reply Quote 0
                                • H
                                  hilfi2000
                                  last edited by

                                  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!

                                  1 Reply Last reply Reply Quote 0
                                  • JeGrJ
                                    JeGr LAYER 8 Moderator
                                    last edited by

                                    Super, danke für die Rückmeldung!

                                    Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

                                    If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post
                                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.