IPsec: Wird http blockiert?



  • Guten Morgen Zusammen,

    beiße mir seit gut einem Monat die Zähne an folgendem Problem aus. Auch die Sufu hat leider nichts vergleichbares erbracht. Vielleicht nutze ich nur die falschen Begriffe…Also:

    Ich habe zwei Standorte via IPsec (IPv4 Tunnel) miteinander verbunden, wie auf http://www.cyberciti.biz/faq/howto-site-to-site-ipsec-vpn-between-cisco-openbsd-router-pfsense/ beschrieben. Läuft soweit alles wie z.B. WinRD von Local-Client auf Remote-Client. Auch http auf Remote-pfSense (webconfig) von meinem Local Client funst. Was nicht geht ist das http auf einen der Remote Clients!?, "Seite nicht verfügbar". Komischerweise funktionierte es noch bevor ich in Urlaub gegangen bin! Soll heißen, es wurden keine Änderungen vorgenommen die darauf Einfluss haben könnten.

    Hier mal die "physikalische Route":
    1 Lokal Client, feste IP 192.168.2.0/24
    2 Lokal pfsense 2.2.6, PPPoE feste externe IP (Telekom)
    3 Lokal Speedport im Betrieb als DSL-Modem
    4 IPsec Tunnel IPv4
    5 Remote Fritte von KD, dynamische IP daher dyndns, Routercascade
    6 Remote pfSense 2.2.6, feste IP 192.168.4.0/24
    7 Remote Client, feste IP, 192.168.4.0/24

    Was ich schon getestet hab:

    • ping von 192.168.2.0/24 zu 192.168.4.0/24 und umgekehrt läuft, auch die Latenzzeit ist bestens (1 <=> 7)
    • tracert hat korrekterweise nur zwei hopps zur Remote-pfSense (1 => 6)und natürlich drei bis zum Remote-Client, wenn der Zweite auch die Zeit überschreitet (1 => 7).
    • keine Firewall loggt irgendwelchen gesperrten traffic (2, 6)
    • Die Firewall der Clients sind zu testen deaktiviert (1, 7).
    • Portfreigaben für IPsec sind eingerichtet (2, 5, 6)
    • VPN Zertifikate sind noch aktuell (2, 6)
    • Laut qnap-scan vom Local-Client ist der Port welchen verwendet wird (nicht 80) auch offen (1 => 7)
    • hab soweit die Paketgröße, MTU auf 1456 bit reduziert, da max bei Telekom (2, 5, 6)
    • http von Remote-Client A auf Remote-Client B funst problemlos (7)
    • Neustart des Tunnels nach den meisten Änderungen (2, 6)
    • temporär auch schon mal ohne den Umweg über dyndns

    Langsam gehen mir die Ideen aus. Welches Werkzeug kann ich noch nutzen für die Verbindung zu prüfen?

    Vorab schon mal Danke für die Hilfe
    Gruß

    Gastro



  • Läuft auf den problematischen Clients vielleicht eine lokale Firewall? Z.B. Windows macht gern mal seine Firewall (wieder) an, und dann geht zwar i.d.R. RDP, aber nix anderes mehr.



  • Danke athurdent,

    hab das mal getestet und die WinFW im Auge behalten. Auch während dessen sie deaktiviert ist komme ich nicht auf den Remote-Client. Ich hatte die entsprechenden Ports auch in den WinFW schon freigegeben. Das gleiche gilt auch für die AVG-FW.

    gastro

    PS: 42!



  • Benutzt Du auf der lokalen pfSense vielleicht Squid oder hat der lokale Client einen anderen Webproxy konfiguriert? Dann mal testweise deaktivieren.
    Du könntest als Workaround auch mal probieren, auf der entfernten pfSense den Squid zu installieren und ihn dazu zu benutzen, mal Port 80 auf dem Client anzusprechen, ob da überhaupt was läuft.
    Dann würde ich Dir auch noch raten, vielleicht lieber OpenVPN statt IPSec zu benutzen. Site to Site IPSec hinter einem Router (KD Fritzbox) ist zwar machbar, aber OpenVPN ist da u.U. fehlerunanfälliger.

    42! :)



  • Wahrscheinlich ne saublöde Frage … aber der Zugriff per http auf den Remoteclient im Remotenetz geht aber schon von einem Client im Remotenetz? Also die Seite ist schon funktionell?!

    Gibt es vielleicht noch einen anderen http Server im Remotenetz, wo man mal grundsätzlich prüfen kann, ob ein http Zugriff überhaupt dorthin möglich ist?



  • Der Zugriff auf die http-Config des/dieser Clients funktioniert innerhalb des Remotenetzes wunderbar.
    Und tatsächlich sind es zwei Clients die erreicht werden sollen. Sie verwenden unterschiedliche Ports für http, kommen sich also nicht gegenseitig in die Quere.