Port-Weiterleitung geht nicht an LAN-IP
-
Hinter der Firewall funktioniert die Zugriff auf 192.168.10.119:55467?
Wenn ja, überprüfe, ob die Pakete überhaupt am WAN ankommen. Diagnostic > Packet capture ist ein geeignetes Werkzeug dafür.
-
intern klappt
test ergebnis:
11:04:48.425481 IP **.55.75.40.3861 > **.151.7.243.55467: tcp 0 11:04:48.425653 IP **.151.7.243.55467 > **.55.75.40.3861: tcp 0 11:04:48.580537 IP **.151.7.243.55467 > **.55.75.40.4273: tcp 0 11:04:49.124544 IP **.151.7.243.55467 > **.51.161.119.40430: tcp 0 11:04:49.444609 IP **.151.7.243.55467 > **.55.75.40.3861: tcp 0 11:04:49.604484 IP **.151.7.243.55467 > **.55.75.40.4381: tcp 0 11:04:50.112103 IP **.122.2.27.4310 > **.151.7.243.55467: tcp 0 11:04:50.112293 IP **.151.7.243.55467 > **.122.2.27.4310: tcp 0 11:04:50.116458 IP **.151.7.243.55467 > **.130.60.20.2867: tcp 0 11:04:50.132337 IP **.130.60.20.2867 > **.151.7.243.55467: tcp 0 11:04:50.237900 IP **.217.58.52.58444 > **.151.7.243.55467: tcp 0 11:04:50.238080 IP **.151.7.243.55467 > **.217.58.52.58444: tcp 0 11:04:50.372473 IP **.151.7.243.55467 > **.55.75.40.1045: tcp 0
-
Das zeigt jetzt aber nicht die in der NAT-Regel angegebene Ziel-IP.
-
Ich hatte Quelle WAN angegeben und Port 55467
und das ist das Ergebnis soll ich die lokale iP auch mit eintragen?wenn ich den Test wie folgt mache kommen 0 Ergebnisse.
-
Okay, das war schon das Ergebnis des Packet capture am WAN?
"Intern klappt es" hatte ich anders verstanden.Wenn das das Pacekt capture zeigt, dann bekommst du aber auch Antworten am WAN raus und der Zugriff müsste eigentlich funktionieren.
Wo liegt nun das Problem? -
Das jetzt aktuell nur teilweise Zugriffe stattfinden. Komischerweise zb Telekom Anschluss aus Dortmund kommt durch Telekom aus Bochum nicht. Kann es an anderen regeln liegen? Hatte regeln für Telekom Entertainment eingetragen obwohl ich keinen habe ich schmeiß die mal raus und hoffe
-
Schalte mal "logging" für die zu NAT gehörende Regel in WAN-Interface ein.
Horch was kommt von draußen rein. -
@gladius
ist eingeschalte wo sehe ich den nun das Ergebnis? -
@baunty said in Port-Weiterleitung geht nicht an LAN-IP:
wo sehe ich den nun das Ergebnis?
Dashboard Widget -> Firewall Logs
sollte eingehende Pakete zeigen.
LG
-
@gladius
die die durchkommen sehe ich aber nicht die die keine Verbindung bekommen.
kann es vielleicht was mit ipv6 Anschlüssen zu tun haben?Sep 23 12:57:35 WAN NAT CC (1537690293) **.**.75.40:2741 192.168.10.119:55467 TCP:S Sep 23 12:57:34 WAN NAT CC (1537690293) **.**.58.52:59290 192.168.10.119:55467 TCP:S Sep 23 12:57:32 WAN NAT CC (1537690293) **.**.204.254:2872 192.168.10.119:55467 TCP:S Sep 23 12:57:31 WAN NAT CC (1537690293) **.**.2.27:1671 192.168.10.119:55467 TCP:S Sep 23 12:57:30 WAN NAT CC (1537690293) **.**.75.40:1356 192.168.10.119:55467 TCP:S Sep 23 12:57:29 WAN NAT CC (1537690293) **.**.8.56:40778 192.168.10.119:55467 TCP:S Sep 23 12:57:27 WAN NAT CC (1537690293) **.**.161.119:40576 192.168.10.119:55467 TCP:S
-
@baunty said in Port-Weiterleitung geht nicht an LAN-IP:
Das jetzt aktuell nur teilweise Zugriffe stattfinden. Komischerweise zb Telekom Anschluss aus Dortmund kommt durch Telekom aus Bochum nicht.
Dann trifft das Thema "Port-Weiterleitung geht nicht an LAN-IP" nicht wirklich zu.
Kann es an anderen regeln liegen? Hatte regeln für Telekom Entertainment eingetragen obwohl ich keinen habe ich schmeiß die mal raus und hoffe
Ich gehe davon aus, dass du in deinen verantwortlichen Firewall-Regeln keine bestimmte Quelle angegeben hast, also die Quelle in den Regeln "any" ist. Ist das so, können die Regeln dafür auch nicht verantwortlich sein und ich würde ein Routingproblem außerhalb deines Einflussbereichs vermuten (bei einem Provider oder im Quell-Netzwerk).
Um der Sache auf den Grund zu gehen, ist wieder Packet Capture geeignet. Einfach prüfen, ob die Pakete am WAN Interface ankommen, wenn aus Bochum eine Verbindung versucht wird.
-
Anfragen kommen an aber werden wohl nicht weitergegeben:
13:17:18.571691 IP **.**.161.119.40620 > **.**.7.243.55467: tcp 0 13:17:23.353130 IP **.**.161.119.40621 > **.**.7.243.55467: tcp 0 13:17:24.355816 IP **.**.161.119.40621 > **.**.7.243.55467: tcp 0
-
@baunty said in Port-Weiterleitung geht nicht an LAN-IP:
werden wohl nicht weitergegeben
Die Pakete kommen also am lokalen Host mittel Portweiterleitung an?
So sollte es sein.LG
-
@gladius
ne sie kommen auf der WAN IP an und das wars nicht am lokalen Server :( -
@baunty
Ob die Firewall hier die Verbindung blockiert, kannst du auch einfach mit Packet Capture prüfen, in dem du es auf dem internen Interface laufen lässt, dann aber mit der Ziel-IP des internen Hosts oder eben mit der Quell-IP.Möglicherweise blockieren pfBlocker oder ein Proxy die Verbindung?
-
mal die Firewall auf dem lokalen Host überprüft? Die Regeln sehen sauber aus. Vielleicht sind weitere Ports oder zusätzlich Protokolle für die Software notwendig, auf die du zugreifen willst/musst.
-
Analysiere die Kommunikation zwischen pfSense (Packet Capture) und dem lokalen Host.
LG
-
Entweder ist das Problem bei Pfsense oder am Modem das vielleicht nicht so viele Verbindungen zugelassen sind. Fritzbox als Router am dsl geht alles. Nur das ist ja nicht mein Ziel. Ziel ist eine Firewall und nicht fritzbox.
Überlegung ist alles platt machen und von 0 neu anfangen.
Noch ne idea Modem vor fritzbox und fritzbox soll über Modem dsl aufbauen -
@viragomann was ist bfBlocker?
-
Das Modem kann es wohl nicht sein, wenn du die Internetanbindung auf der pfSense via PPPoE herstellst (so sieht es für mich aus). In diesem Fall kann das Modem nicht filtern.
Auf der pfSense lässt sich das Logging für alle Regel aktivieren, auch das der Defaul (deny) Regel. System > Logs > Settings.
Wenn alles aktiviert ist, sollten die Blocks zu finden sein.Doch hatten hier auch schon andere unerklärbare Phänomene und nach einer Neuinstallation hat es geklappt.
@baunty said in Port-Weiterleitung geht nicht an LAN-IP:
@viragomann was ist bfBlocker?
pfBlockerNG > ein installierbares Paket (über Packetmanager), in erster Linie ein GEO-Blocker