14.12.2022, aktualisiert um 12:40:50 Uhr

2951

Routing zwischen LAN und OPT1 PFSense

Hallo zusammen,

ich stehe gerade auf dem Schlauch. Ich habe eine PFSense 2.6.0 mit WAN, LAN und OPT1. Auf LAN ist das normale Netzwerk und auf dem OPT ist ein extra Netz mit genau einem Gerät dran, dass nämlich Rechnungen verschickt. Dieses Tool darf vom Hersteller aus nicht im selben Netz sein. Nun war es doch bei PFSense so, wenn ich die Default Rule drinnen habe

Protocol: IPv4*
Source: LAN Net
Port: *
Destination: *
Port: *
Gateway: *

und das selbe auf dem OPT1 Anschluss, einfach mit OP1 Net. Das bisher, wenn mich nicht alles täuscht ich das Gerät vom LAN erreichen konnte. Ich kann auf der PFSense unter Ping die IP auch pingen wenn ich vom OPT1 pinge aber eben nicht vom LAN aus.

Ich müsste nämlich vom LAN auf OPT1 Gerät zugreifen können um Daten zu versenden.

Kann mit jemand sagen wo ich gerade auf dem Schlauch stehe? Selbst bei einer Regel auf OPT1 mit Allow * from LAN Net zu OPT1 Net geht es nicht.

Lg

P.S. Ich komme von LAN über die Gateway IP von OPT1 aber auf die PFSense Oberfläche.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 4958106408

Url: https://administrator.de/contentid/4958106408

Ausgedruckt am: 22.11.2024 um 08:11 Uhr

18 Kommentare

Neuester Kommentar

Hi,
klingt erstmal soweit korrekt. Hast du bei dem Gerät im OPT1 Netz die IP vom OPT1-Port als Gateway eingetragen? Und bei den Geräten im LAN-Netz die IP des LAN-Ports als Gateway?
Hast du irgendwelche statischen Routen eingetragen oder doppelte Subnetz? Gleiches Subnetz am WAN wie im OPT z.B. o.ä.? Was für Subnetzmasken hast du an den jeweiligen Ports der pfSense und stimmen diese auch an den Clients überein?

MfG

Also auf dem LAN Netz übernimmt der Windows Server die DHCP Rolle und gibt als Gateway die IP aus. Beim OPT1 habe ich auf der PFSense einen DHCP laufen der auch dem Gerät die IP vergibt. Der Hersteller sieht auch das sein Gerät online ist und mit ihnen kommuniziert. Ich habe keine Routings eingerichtet und es sind beides /24 Netze. Hier mal schnell die Settings.

Moin,

.. mit genau einem Gerät dran, dass nämlich Rechnungen verschickt.

beschreibe mal, was das Gerät ist.
Eine Windows-Büchse?
Hast du die dortige Firewall angepasst, dass auch das LAN-Netz zugreifen darf?

Gruß
em-pie

Welche IP hat das Gerät im OPT1-Netz bekommen? Was sagt denn ein tracert 192.168.2.<ip-im-opt1-netz> vom z.B. Windows-Server (IP?) aus?

Kann mit jemand sagen wo ich gerade auf dem Schlauch stehe?

Nirgendwo! Regeltechnisch hast du alles richtig gemacht. Wenn man einmal davon absieht das das Scheunentor Regeln sind die alles überallhin erlauben. Damit konterkariert man eigentlch eine Firewall per se aber so sollten sich natürlich beide IP Netze problemlos erreichen können.
Kosmetisch könnte man noch korrigieren das du den DHCP Pool sicherheitshalber etwas verkleinern solltest in einen festen Bereich z.B. .10-.200 und die Lease Time auf die Local Time setzen. Wie gesagt alles kosmetisch und hat mit dem Ruleset nichts zu tun.

Man kann nur vermuten das dein Gerät an OPT1 ein Windows Endgerät ist und dir dort die lokale Firewall dazwischenfunkt, denn diese blockt im Default generell Traffic aus anderen IP Netzen und auch ICMP Traffic (Ping)
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Ansonsten einmal mit ipconfig checken ob die Gateways auf beiden Seiten stimmen und auch einmal ins Firewall Log sehen ob du nicht doch einen Tippfehler im Ruleset gemacht hast und dort etwas blockst.

Tip:
Wenn du schon einen zentralen DHCP Server auf dem Windows Server betreibst kannst du den auch zentral für alle Segmente IPs vergeben lassen. So hast du einen zentralen Managementpunkt für alle deine Client IPs. Ein weiterer Vorteil ist das dann auch lokale DNS Namen aufgelöst werden.
Dazu ist in der Firewall lediglich dann nur DHCP Relay einzustellen:
https://docs.netgate.com/pfsense/en/latest/services/dhcp/relay.html
Du ersparst dir damit die Frickelei mit 2 DHCP Servern und ggf. daraus resultierenden Fehlern!

Also das Endgerät ist kein Windows PC. Das ist eine kleine Box auf denen irgendein Unix läuft. Es ist so das die Zywall USG letzte Woche abgelegen ist und dort war die Konfiguration die selbe. Ein Port mit dem 192.168.2.1 Lan und eben dem DHCP drauf und das Gerät dort angemeldet. Auf die Box von der Firma kann ich selber nicht zugreifen. Das ist sozusagen so:

Kunde bekommt Box geschickt.
Muss in einem anderen LAN sein wie der Server und die dort genutzte Software
Rechnungen werden für Kunden in Software erstellt und dann über die Box an den Dienstleister der dann den Rest macht gesendet.

Wenn Du die Regeln protokollierst und Dir beim Zugriff das Log anschaust, kannst Du ja sehen, ob er das auf der PFSense blockiert oder eben durchlässt, dann wäre, wie angesprochen, eher das Endgerät vermutlich das Thema.

Zitat von @greaman:

Wenn Du die Regeln protokollierst und Dir beim Zugriff das Log anschaust, kannst Du ja sehen, ob er das auf der PFSense blockiert oder eben durchlässt, dann wäre, wie angesprochen, eher das Endgerät vermutlich das Thema.

Moin,

ich würde es genau so machen.
Zum Testen kannst du dann eine Outbound NAT Rule auf dem OPT1 Interface anlegen und mal in das Netz naten. Ich denke das hier nur die "Box" nicht antwortet da die Anfragen oder Pings aus einem anderen Netz kommen.

Gruß
Spirit

Sehr hilfreich wäre auch die Paket Capture Funktion im "Diagnostics" Menü. Dort startest du am OPT1 Port ein Capture und gibst als Host IP die Adresse der Box ein.
Dann schneidet die Firewall allen Traffic von und zu diesem Host mit. Wenn du dann parallel mal einen Ping auf diese Box IP ausführst kannst du im Capture genau sehen ob der Ping Traffic überhaupt in dem Segment ankommt und ob die Box darauf antwortet.
Du kannst dir den Trace direkt an der FW ansehen im GUI besser weil deutlich übersichtlicher ist es aber den Tracefile runterzuladen und im Wireshark anzusehen!

Guten Morgen zusammen, also ich hab mal das mit der Log gemacht und eben das mit dem Packet Capture. Wenn ich von LAN auf Host Adress gehe habe ich nur solche Einträge:

09:48:20.075546 IP 172.17.XX.XX > 192.168.2.11: ICMP echo request, id 1, seq 15957, length 40
09:48:25.073531 IP 172.17.XX.XX > 192.168.2.11: ICMP echo request, id 1, seq 15958, length 40
09:48:30.976614 IP 172.17.XX.XX > 192.168.2.11: ICMP echo request, id 1, seq 15959, length 40
09:48:33.537927 IP 172.17.XX.XX > 192.168.2.11: ICMP echo request, id 1, seq 15960, length 40
09:48:38.074101 IP 172.17.XX.XX > 192.168.2.11: ICMP echo request, id 1, seq 15961, length 40
09:48:43.075967 IP 172.17.XX.XX > 192.168.2.11: ICMP echo request, id 1, seq 15962, length 40
09:48:48.075822 IP 172.17.XX.XX > 192.168.2.11: ICMP echo request, id 1, seq 15963, length 40
09:48:53.075184 IP 172.17.XX.XX > 192.168.2.11: ICMP echo request, id 1, seq 15964, length 40
09:48:55.060599 IP 172.17.XX.XX.50329 > 192.168.2.11.8100: tcp 0
09:48:55.311361 IP 172.17.XX.XX.50330 > 192.168.2.11.8100: tcp 0
09:48:58.061456 IP 172.17.XX.XX.50329 > 192.168.2.11.8100: tcp 0
09:48:58.075583 IP 172.17.XX.XX > 192.168.2.11: ICMP echo request, id 1, seq 15965, length 40
09:48:58.311468 IP 172.17.XX.XX.50330 > 192.168.2.11.8100: tcp 0

Das mit dem Port 8100 ist eben eine URL über welche die Software die Daten austauscht. Soviel weiss ich nun schon mal. Wenn ich im Browser versuche dies zu öffnen. Firewall sagt auf meiner Regel:

ich hab mal das mit der Log gemacht

Das Log ist sächlich...aber egal.
Dein Logging zeigt das Ping oder TCP 8100er Pakete von 172.17.XX.XX auf die 192.168.2.11 gehen.
Dummerweise hast du leider vergessen mittzuteilen ob du am LAN oder am OPT1 Port gecaptured hast.

Man kann aber (vermutlich) sagen das die Ping Echo Reply Pakete bzw. TCP 8100, sprich also die Antwort von 192.168.2.11 zurück zur 172.17.XX.XX nicht ankommt oder gar nicht gesendet werden.

Sinnvoll ist also dann einmal am OPT1 Port zu capturen um zu sehen ob überhaupt Reply Pakete von 192.168.2.11 kommen oder ob dieser Host gar nicht erst antwortet. Du kannst ja auch sehen das auf die TCP 8100 Connection Requests keinerlei Antwort kommt.
Da du aber leider nicht mitteilst WO du gemessen hast kann man leider nur weiter kristallkugeln hier und so gestaltet sich ein zielführendes Troubleshooting natürlich nicht gerade einfach wenn man zig mal nachfragen muss um einen Sachverhalt zu klären.

Normal erledigt die Firewall sowas out of the box mit der Default Konfig ohne viel Setup Gefummel. 2 "IP net to any" Scheunentor Regeln an den Ports und fertig ist der Lack.
Man könnte vermuten das die Box sich gar nicht hinter der IP 192.168.2.11 verbirgt sondern eine ganz andere IP hat oder sich gar nicht an dem OPT1 Port befindet und deshalb alle Anfragen an die 192.168.2.11 ins Leere laufen.
WIE bekommt denn die Box ihre IP? Statisch oder DHCP?

Wenn DHCP hast du im Diagnostics Menü einmal in die leases fürs OPT1 Segment gesehen ob die Box auch wirklich diese IP bekommen hat?
Hast du dann mal über das Ping Tool im Diagnostics Menü versucht diese Box IP zu pingen. Sehr wichtig ist hier einmal die Absender IP auf "OPT1" zu setzen und einmal auf "LAN" um zu checken das diese IP auch aus beiden Segmenten erreichbar ist.

Irgendwas rennt da grundsätzlich falsch in deinem Setup?!
Ggf. mal strategisch vorgehen und mal einen bedienbaren Testrechner in das OPT1 Segment stecken und auf den auch die o.a. Pings aus dem Diagnostics Menü ausführen und auch vice versa von diesem Testrechner auf alle beteiligten IPs in OPT1 und LAN.
So kannst du überhaupt erstmal sicher testen das dein OPT1 Segment so rennt wie es soll. Wenn das der Fall ist dann verfrachtest du die Box da rein.

Hallo Aqui,

also wenn ich über den Ping gehe auf der PFSense und von OPT1 die 2.11 pinge, dann bekomme ich eine Antwort. Wenn ich von LAN pinge bekomme ich keine. Ich hab hier nun mal eben das Capture mit dem Versuch in der Zeit auf die URL zuzugreifen. Capture ist vom OPT1. Ach ja DHCP vergibt die IP.

10:29:58.134587 IP 172.17.96.241.50639 > 192.168.2.11.8100: tcp 0
10:29:58.385494 IP 172.17.96.241.50640 > 192.168.2.11.8100: tcp 0
10:29:59.712822 IP 192.168.2.11.39311 > 192.168.2.1.53: UDP, length 34
10:29:59.712966 IP 192.168.2.11.39311 > 192.168.2.1.53: UDP, length 34
10:29:59.728242 IP 192.168.2.1.53 > 192.168.2.11.39311: UDP, length 111
10:29:59.743185 IP 192.168.2.1.53 > 192.168.2.11.39311: UDP, length 111
10:29:59.743510 IP 192.168.2.11.58802 > 192.168.2.1.53: UDP, length 39
10:29:59.743576 IP 192.168.2.11.58802 > 192.168.2.1.53: UDP, length 39
10:29:59.743674 IP 192.168.2.1.53 > 192.168.2.11.58802: UDP, length 114
10:29:59.743888 IP 192.168.2.1.53 > 192.168.2.11.58802: UDP, length 114
10:29:59.744112 IP 192.168.2.11.37100 > 192.168.2.1.53: UDP, length 24
10:29:59.744177 IP 192.168.2.11.37100 > 192.168.2.1.53: UDP, length 24
10:29:59.744267 IP 192.168.2.1.53 > 192.168.2.11.37100: UDP, length 99
10:29:59.744425 IP 192.168.2.1.53 > 192.168.2.11.37100: UDP, length 99
10:30:01.134689 IP 172.17.96.241.50639 > 192.168.2.11.8100: tcp 0
10:30:01.386258 IP 172.17.96.241.50640 > 192.168.2.11.8100: tcp 0
10:30:02.525542 IP 192.168.2.11.56617 > 192.168.2.1.53: UDP, length 69
10:30:02.525709 IP 192.168.2.11.56617 > 192.168.2.1.53: UDP, length 69
10:30:02.526043 IP 192.168.2.1.53 > 192.168.2.11.56617: UDP, length 144
10:30:02.526143 IP 192.168.2.1.53 > 192.168.2.11.56617: UDP, length 144
10:30:02.526351 IP 192.168.2.11.46684 > 192.168.2.1.53: UDP, length 79
10:30:02.526415 IP 192.168.2.11.46684 > 192.168.2.1.53: UDP, length 79
10:30:02.557534 IP 192.168.2.1.53 > 192.168.2.11.46684: UDP, length 156
10:30:02.572376 IP 192.168.2.1.53 > 192.168.2.11.46684: UDP, length 156
10:30:02.572731 IP 192.168.2.11.33915 > 192.168.2.1.53: UDP, length 84
10:30:02.572847 IP 192.168.2.11.33915 > 192.168.2.1.53: UDP, length 84
10:30:02.573112 IP 192.168.2.1.53 > 192.168.2.11.33915: UDP, length 159
10:30:02.573330 IP 192.168.2.1.53 > 192.168.2.11.33915: UDP, length 159
10:30:02.576579 IP 192.168.2.11.41407 > 192.168.2.1.53: UDP, length 90
10:30:02.576987 IP 192.168.2.1.53 > 192.168.2.11.41407: UDP, length 149
10:30:04.447025 IP 192.168.2.11.58512 > 192.168.2.1.53: UDP, length 69
10:30:04.447146 IP 192.168.2.11.58512 > 192.168.2.1.53: UDP, length 69
10:30:04.447398 IP 192.168.2.1.53 > 192.168.2.11.58512: UDP, length 144
10:30:04.447564 IP 192.168.2.1.53 > 192.168.2.11.58512: UDP, length 144
10:30:04.447723 IP 192.168.2.11.55672 > 192.168.2.1.53: UDP, length 79
10:30:04.447789 IP 192.168.2.11.55672 > 192.168.2.1.53: UDP, length 79
10:30:04.447954 IP 192.168.2.1.53 > 192.168.2.11.55672: UDP, length 156
10:30:04.447957 IP 192.168.2.1.53 > 192.168.2.11.55672: UDP, length 156
10:30:04.448231 IP 192.168.2.11.60301 > 192.168.2.1.53: UDP, length 84
10:30:04.448298 IP 192.168.2.11.60301 > 192.168.2.1.53: UDP, length 84
10:30:04.448415 IP 192.168.2.1.53 > 192.168.2.11.60301: UDP, length 159
10:30:04.448555 IP 192.168.2.1.53 > 192.168.2.11.60301: UDP, length 159
10:30:04.449938 IP 192.168.2.11.37671 > 192.168.2.1.53: UDP, length 90
10:30:04.450109 IP 192.168.2.1.53 > 192.168.2.11.37671: UDP, length 149
10:30:04.720170 ARP, Request who-has 192.168.2.1 tell 192.168.2.11, length 46
10:30:04.720194 ARP, Reply 192.168.2.1 is-at 00:0d:b9:5d:d2:43, length 28
10:30:06.387900 IP 192.168.2.11.55339 > 192.168.2.1.53: UDP, length 69
10:30:06.388082 IP 192.168.2.11.55339 > 192.168.2.1.53: UDP, length 69
10:30:06.388398 IP 192.168.2.1.53 > 192.168.2.11.55339: UDP, length 144
10:30:06.388570 IP 192.168.2.1.53 > 192.168.2.11.55339: UDP, length 144
10:30:06.388754 IP 192.168.2.11.58138 > 192.168.2.1.53: UDP, length 79
10:30:06.388822 IP 192.168.2.11.58138 > 192.168.2.1.53: UDP, length 79
10:30:06.388987 IP 192.168.2.1.53 > 192.168.2.11.58138: UDP, length 156
10:30:06.388991 IP 192.168.2.1.53 > 192.168.2.11.58138: UDP, length 156
10:30:06.389267 IP 192.168.2.11.45094 > 192.168.2.1.53: UDP, length 84
10:30:06.389363 IP 192.168.2.11.45094 > 192.168.2.1.53: UDP, length 84
10:30:06.389425 IP 192.168.2.1.53 > 192.168.2.11.45094: UDP, length 159
10:30:06.389567 IP 192.168.2.1.53 > 192.168.2.11.45094: UDP, length 159
10:30:06.391021 IP 192.168.2.11.60451 > 192.168.2.1.53: UDP, length 90
10:30:06.391228 IP 192.168.2.1.53 > 192.168.2.11.60451: UDP, length 149
10:30:07.135064 IP 172.17.96.241.50639 > 192.168.2.11.8100: tcp 0
10:30:07.387092 IP 172.17.96.241.50640 > 192.168.2.11.8100: tcp 0
10:30:20.738548 IP 192.168.2.11.68 > 192.168.2.1.67: UDP, length 303
10:30:20.740555 IP 192.168.2.1.67 > 192.168.2.11.68: UDP, length 300
10:30:42.570243 IP 192.168.2.11.38883 > 192.168.2.1.53: UDP, length 33
10:30:42.570624 IP 192.168.2.1.53 > 192.168.2.11.38883: UDP, length 49
10:30:42.572081 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 0
10:30:42.576550 IP 195.65.9.76.443 > 192.168.2.11.60054: tcp 0
10:30:42.576940 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 0
10:30:42.579509 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 231
10:30:42.583446 IP 195.65.9.76.443 > 192.168.2.11.60054: tcp 0
10:30:42.583979 IP 195.65.9.76.443 > 192.168.2.11.60054: tcp 1448
10:30:42.584091 IP 195.65.9.76.443 > 192.168.2.11.60054: tcp 1448
10:30:42.584145 IP 195.65.9.76.443 > 192.168.2.11.60054: tcp 1200
10:30:42.584379 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 0
10:30:42.584505 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 0
10:30:42.584837 IP 195.65.9.76.443 > 192.168.2.11.60054: tcp 1448
10:30:42.584992 IP 195.65.9.76.443 > 192.168.2.11.60054: tcp 1448
10:30:42.585021 IP 195.65.9.76.443 > 192.168.2.11.60054: tcp 1122
10:30:42.585268 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 0
10:30:42.585319 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 0
10:30:42.585392 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 0
10:30:42.593435 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 75
10:30:42.602282 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 6
10:30:42.602598 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 45
10:30:42.606286 IP 195.65.9.76.443 > 192.168.2.11.60054: tcp 0
10:30:42.606646 IP 195.65.9.76.443 > 192.168.2.11.60054: tcp 51
10:30:42.610496 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 592
10:30:42.621495 IP 195.65.9.76.443 > 192.168.2.11.60054: tcp 275
10:30:42.622594 IP 195.65.9.76.443 > 192.168.2.11.60054: tcp 34
10:30:42.622927 IP 192.168.2.11.60054 > 195.65.9.76.443: tcp 0
10:30:42.868620 IP 192.168.2.11.35610 > 192.168.2.1.53: UDP, length 33
10:30:42.868850 IP 192.168.2.1.53 > 192.168.2.11.35610: UDP, length 49
10:30:42.869803 IP 192.168.2.11.51432 > 195.65.9.76.443: tcp 0
10:30:42.874102 IP 195.65.9.76.443 > 192.168.2.11.51432: tcp 0
10:30:42.874462 IP 192.168.2.11.51432 > 195.65.9.76.443: tcp 0
10:30:42.879579 IP 192.168.2.11.51432 > 195.65.9.76.443: tcp 231
10:30:42.883471 IP 195.65.9.76.443 > 192.168.2.11.51432: tcp 0
10:30:42.884168 IP 195.65.9.76.443 > 192.168.2.11.51432: tcp 1448
10:30:42.884202 IP 195.65.9.76.443 > 192.168.2.11.51432: tcp 1448

also wenn ich über den Ping gehe auf der PFSense und von OPT1 die 2.11 pinge, dann bekomme ich eine Antwort.

Wie gesagt mit welcher Absender IP pingst du???
Kommt die Antwort sowohl wenn du die Absender IP auf OPT1 legst und auch auf LAN???

Ich bekomme nur vom OPT1 eine Antwort beim Ping. Wenn ich auf LAN wechsel kann er sie nicht mehr pingen. Pinge von der PFSense aus unter Diagnostics -> Ping

OK, das ist dann schon ein Fehler. Das darf so nicht sein. Du hast also irgendwas in den Settings so verändert das die FW (vermutlich) nicht mehr routet. Oder...dein Regelwerk stimmt nicht. (Es fehlt immer noch ein Screenshot der OPT1 Regeln!)

Bevor wir uns alle schwarz suchen nach dem Fehler: Setze die pfSense auf ihre Factory Defaults zurück und setze das ganze nochmal neu auf.

Keine Fummelei an der Grundkonfig
und nur das OPT1 über das Assignement hinzufügen und aktivieren
DHCP Server bei Bedarf auf dem OPT1 aktivieren.
An beiden Interfaces Scheunentor Regeln "Pass: IP local.net -> any"
Fertisch

So ein spannendes Update. Also es ist wirklich alles richtig auf meiner Seite. Wenn man in der Software der Firma die IP gelöscht und wieder rein gemacht hat, geht es auf einmal. Vielen lieben Dank euch allen für den Input. Nun hab ich die Regeln beschränkt auf die IP aber die Lösung lag anscheinend am neu setzten der IP.