IPSec Site-to-Site VPN - HTTP Traffic

Hallo zusammen

Ich habe ein spezielles Phänomen, aus welchem ich nicht schlau werden.

 

Ich habe ein Site-to-Site VPN zwischen 192.168.0.0/24 und 192.168.100.0/24. Dabei ist auf dem 100er Subnetz Seite NAT-T aktiv.

Die IPSec Verbindung steht

 

Ich kann von beiden Seiten auf die andere Seite per SSH oder RDP verbinden, somit scheint die Verbindung in Ordnung zu sein.

- Greife ich von 192.168.0.0/24 auf einen Webservice im 192.168.100.0/24 er Netz zu, so funktioniert der Zugriff.

- Greife ich vom 192.168.100.0/24 Netz auf ein Webservice im 192.168.0.0/24 Netz zu, so erhalte ich ein Timeout. Die Firewall ist aber grundsätzlich offen, eine Verbindung mittels telnet auf Port 80 des Webservices funktioniert zum Beispiel.

TCPDump zeigt mir folgendes an:

 

Ich vermute ein Problem im Zusammenhang mit NAT, habe aber keine Ahnung wo ich suchen muss.

 

Danke für eure Hilfe.

  • Hallo,

    das NAT-T ist nur dafür da, dass der Tunnel auch über NAT-Grenzen hinweg aufgebaut werden kann.

    Wenn keine weiteren NAT-regeln existieren, ist es nicht NAT.

    Die Verbindung scheint ja prinzipiell zu funktionieren, auch wenn es zu Paketwiederholungen und Neuübertragungen kommt.

    Ich würde eher auf ein Hardwareproblem an einer der Verbindungen tippen. 

    In Frage kommen da NIC, Kabel, Full-/Halbduplex-Einstellungen.

  • Immer auch die interne Firewalls (Windows Defender bei aktuellen Server Systemen) oder AV-Lösungen mit Firewallfunktionalität in Betracht ziehen und prüfen. Für den entfernten Server kommen die Anfragen ohne NAT ja aus einem "fremden" Netzwerk und könnten dadurch geblockt werden...

     

    Gruß Steve

     

     

     

  • In reply to Steve Weißflog:

    Hallo Steve,

    für ein echtes, gezieltes  "blocken", egal durch wen oder was, kommt dann doch zu viel durch.

    Das TCP Handshaking SYN - SYN ACK - ACK ist z.B. vollständig, auch wenn des SYN ACK wiederholt wird.

    Von den anderen Paketen kommen trotz Paket-Verlusten und-wiederholungen ja auch einige an.

     

    Und wenn eine Richtung deutlich besser funktioniert als die andere ... würde ich wirklich auf einen Full-Duplex/Halb-Duplex mismatch tippen.

    @Martin: Ist im Netz/Server irgendwo die Portgeschwindigkeit fest eingestellt?

  • In reply to dirkkotte:

    Hallo Dirk 

    Danke für die Hinweise.

    Nein, alle Interfaces, welche ich konfigurieren kann, sind beidseitig auf Auto-Nego eingestellt.

     

    Gruss, Martin

  • Hallo Martin,

    Herzlich willkommen hier in der Community !

    (Sorry, my German-speaking brain isn't creating thoughts at the moment.  )

    I don't believe this traffic is being blocked by the UTM, but you could confirm that by doing #1 in Rulz (last updated 2019-04-17).  #2 in Rulz will help you understand how inbound packets are handled.

    I almost always agree with what Dirk and Steve post, but my guess here is DNS or a routing issue in your home device.  If you're using Web Filtering on the other side, that might be a part of the solution.

    MfG - Bob (Bitte auf Deutsch weiterhin.)

  • In reply to BAlfson:

    Hallo Bob

    Danke für deine Antwort.

    WebFiltering ist nicht aktiv.

    IPS war deaktiviert, die Rules in den einzelnen Tabs habe ich zur Sicherheit auch deaktiviert.

    DNS dürfte es nicht sein, da ich den Ziel-Webserver via IP:Port und nicht per FQDN anspreche

    Das Routing müsste die UTM für den Tunnel selbst machen oder benötigt es dazu eine manuelle konfiguration?

     

    Danke und Gruss

    Martin

  • In reply to Martin Kronenberg:

    Was mir im Firewall Log aufgefallen ist:

    Rufe ich den Webservice per IP auf, habe ich jedesmal den folgenden Firewall Eintrag:

    Wobei 172.16.1.254 die IP des UTM WAN Interfaces ist und 172.16.1.1 des Routers

    Schalte ich dies auf der Firewall frei, klappt es aber leider trotzdem nicht.

  • In reply to Martin Kronenberg:

    Hallo Martin,

    Was sagt den der Webserver im Log, bekommt er die Anfragen?

  • In reply to Martin Kronenberg:

    Hallo Martin,

    If you read #1 in Rulz closely, you see that disabling IPS does not disable Anti-UDP-Flooding, so you really should check that log, too.

    Alone among the logs, the Firewall Live Log presents abbreviated information in a format easier to read quickly.  Usually, you can't troubleshoot without looking at the corresponding line from the full Firewall log file.  Please post the line corresponding to the one above in red.

    MfG - Bob (Bitte auf Deutsch weiterhin.)

  • In reply to JosefBergmann:

    Hallo Josef

     

    Spannend ist, wenn ich den Webservice des NAS via HTTP aufrufen erhalte ich:

     

    Rufe ich den gleichen Webservice via HTTPS auf, habe ich das in diesem Case beschriebene Verhalten.
    Ist ein Webservice nur via HTTP erreichbar, tritt ebenfalls das hier beschriebene Verhalten auf.

     

    Grundsätzlich scheint aber somit, der Request anzukommen. Die Webserverlogs muss ich noch prüfen, habe von hier aus keinen Zugriff.

     

    Danke und Gruss
    Martin

  • In reply to BAlfson:

    Hallo Bob

     

    Das Anti-UDP-Flooding habe ich explizit deaktiviert:

    Das IPS-Logfile ist bei mir leer:

     

    Es ist diese Logzeile:

    2020:02:08-11:32:58 sophosutm ulogd[4728]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth0" srcmac="94:6a:b0:cb:e0:3a" dstmac="00:0d:b9:37:19:d8" srcip="172.16.1.1" dstip="172.16.1.254" proto="17" length="78" tos="0x00" prec="0x00" ttl="64" srcport="45812" dstport="137"

     

    Was mir im Log auffällt, dass ich zu dieser Zeit generell sehr viele Blocks mit dstport="137" im internen Netz habe.

     

    Danke und Gruss
    Martin

  • In reply to Martin Kronenberg:

    Hallo,

    ich glaube, das Thema mit UDP137 an deine(n) Server kannst du ignorieren.

    Wenn du den mittels IP ansprichst, versucht der Browser/Client lediglich den Namen zur IP per NetBios vom Server zu erfragen.

    Habe noch nicht gesehen, dass etwas nicht funktionierte, wenn ich das blockte.

    Ich habe noch ein paar weitere Fragen...

    Welche Firewalls werden auf beiden Seiten eingesetzt?

    Schlägt das IPS-auf einer der beiden an?

    Ist es möglich eine Datei per SSH/SCP durch den Tunnel auf den Problem-Webserver und zurück zu kopieren? Wie lange dauert das pro Richtung?

  • In reply to dirkkotte:

    Auf der "NAT" Seite ist die Sophos UTM im Einsatz, davor ist die SALT Fiber Box für den Internetzugang.

    Auf der gegenseite eine Swisscom CentroBusiness 2, welche als Router/Firewall und IPSec funktioniert.

     

    Nein. Ich kann mich mit WinSCP vom NAT-Netz zwar verbinden, sobald ich im Datenverzeichnis navigieren möchte, erhalte ich ein Timeout:

     

    Gruss, Martin

  • In reply to Martin Kronenberg:

    Vom "Nicht-NAT" Netz, wo die Verbindung zur Remote Seite funktioniert:

     

    Vom "NAT" Netz:

  • In reply to Martin Kronenberg:

    Ich habe neue Erkenntnisse. 
    Bei reinen HTTP Services kann ich die Verbindung nun aufbauen und die Dienste nutzen, jedoch bei HTTPS tritt der Fehler nach wie vor auf.

    Bei HTTPS gelange ich bis zur Fehlermeldung des Zertifikates. Klicke ich dann auf "Trotzdem laden" bleibt die Seite stehen:

     

    Wireshark sagt dazu: