[Gelöst] pfSense blockiert LAN-Verbindungen



  • Hallo Forum,
    mein pfSense "blockiert" seit Anfang August alle Verbindungen.
    Hier meine Konfiguration:
    LAN: feste IP 192.168.7.1, DHCP aktiviert, ich komme von den Rechnern in diesem Netzwerk auf die Konfigurationsoberfläche meines pfSense
    WAN: Adresse über DHCP vom Telekom Router (192.168.8.6) - akktuell hat der WAN die 192.168.8.101.

    Über die Weboberfläche funktioniert der Ping überallhin, z.B. www.heise.de.
    Vom Rechner im 192.168.7.xxx-er Netzwerk (z.B. 192.168.7.102) funktioniert der Ping nur bis zum WAN (192.168.8.101) - der Telekomrouter (192.168.8.6) antwortet schon nicht mehr.

    Wenn ich über die Weboberfläche den Verkehr auf WAN capture kommt folgendes raus:
    18:23:19.315612 IP 192.168.8.101 > 192.168.8.6: ICMP echo request, id 41338, seq 19725, length 44
    18:23:19.316241 IP 192.168.8.6 > 192.168.8.101: ICMP echo reply, id 41338, seq 19725, length 44
    18:23:19.734922 ARP, Request who-has 192.168.8.234 tell 192.168.8.6, length 46
    18:23:20.131236 IP 192.168.7.102 > 193.99.144.85: ICMP echo request, id 512, seq 11008, length 40
    18:23:20.315705 IP 192.168.8.101 > 192.168.8.6: ICMP echo request, id 41338, seq 19981, length 44
    18:23:20.316270 IP 192.168.8.6 > 192.168.8.101: ICMP echo reply, id 41338, seq 19981, length 44
    18:23:20.736122 ARP, Request who-has 192.168.8.234 tell 192.168.8.6, length 46
    18:23:21.315808 IP 192.168.8.101 > 192.168.8.6: ICMP echo request, id 41338, seq 20237, length 44
    18:23:21.316396 IP 192.168.8.6 > 192.168.8.101: ICMP echo reply, id 41338, seq 20237, length 44
    18:23:22.315894 IP 192.168.8.101 > 192.168.8.6: ICMP echo request, id 41338, seq 20493, length 44
    18:23:22.316424 IP 192.168.8.6 > 192.168.8.101: ICMP echo reply, id 41338, seq 20493, length 44
    18:23:23.315995 IP 192.168.8.101 > 192.168.8.6: ICMP echo request, id 41338, seq 20749, length 44
    18:23:23.316452 IP 192.168.8.6 > 192.168.8.101: ICMP echo reply, id 41338, seq 20749, length 44

    Irgendwie hat das für mich den anschein, als ob der Verkehr von LAN rauswärts funktioniert, die Antwort aber nicht durchgelassen wird…
    Die Firewall-Rules sollten passen...
    Hat jemand eine Idee?

    Danke,
    Andi



  • Moment ich such noch eben die Glaskugel….. :D Spaß beiseite.

    Die Infos reichen nicht wirklich.

    Die Ursachen können Viele sein und die Aussage "die Firewall-Rules sollten passen" helfen da nicht gerade.

    Wenn du schreibst.. Die Firewall blockt seit August alles aus dem LAN, gehe ich davon aus, dass vorher alles funktioniert hat.

    Welche Änderungen sind in diesem Zeitraum gemacht worden ? (Unter Diagnostics->Backup/Restore gibts den Reiter "Config History")
    Eventuell auf den letzt funktionierenden Konfigstand zurückspringen.

    Mögliche Ursachen wären aber...

    Fehlender Nat-Translation Eintrag
    Firewall Regel

    Es kann aber auch was ganz anderes sein.



  • Hallo,

    Änderungen sind keine gemacht worden - der Rechner steht bei einer bekannten und die "verwendet" die Firewall nur und hat keinen Konfigurationsszugriff darauf.
    Es sind in der "Config History" nur Einträge seit gestern zu sehen, als ich angefangen habe, zumzufuhrwerken.
    Auch an der Netzwerktopologie oder sonstiges hat sich nichts geändert.
    Ich hab den Rechner nun bei mir und diagnostiziere hier weiter…

    Bei Firewall : NAT ist nur bei Outbound der Eintrag Automatic aktiviert, ansonsten ist NAT leer - ich dachte das reicht.
    Bei den Firewall Regeln hab ich auch schon mit "any" in beiden Netzwerken experimentiert.

    Wie gesagt funktionieren die Ping's von der Web-Oberfläche in die Welt, aber ein Ping vom LAN verhallt...

    Gruß,
    Andi



  • Outbound NAT auf Auto reicht in der Regel auch, es gibt aber auch User (wie Ich) bei denen es auf Manual steht.

    Das Problem ist, wenn es vorher funktioniert hat und es keine Änderungen gab, wird es mit Ferndiagnostik mangels Infos schwierig.

    Was steht denn im Firewall-Regel-Log und Systemlog.
    Bekommen die Clients den Default-Gateway übermittelt und werden DNS-Anfragen am Client aufgelöst.
    Läuft Squid als Transparentproxy (Wenn ja, läuft der Dienst).
    Ist der Ram oder die Systemplatte voll
    ….
    ..
    .

    Fragen über Fragen und nur du kannst es uns sagen  ;)



  • Hallo,
    mein Problem ist wohl die Mühle, auf der die Firewall installiert ist.
    Schon bei der Neuinstallation macht diese Kiste nur Macken und läuft nicht richtig.
    Auf einem anderen Rechner installiert, die Config zurückgespielt und angepasst und alles läuft wie am Schnürchen…
    Bedankt!
    Andi



  • Danke für die Rückmeldung und schön das die Ursache gefunden wurde.