letstryandfindout
Dec 14, 2022, updated at 11:40:50 (UTC)
view2409
view18
0
Goto Top

Routing zwischen LAN und OPT1 PFSense

GermansolvedQuestionFirewall
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.
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 4958106408

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

Printed on: April 28, 2024 at 09:04 o'clock

18 Comments
Latest comment
Goto Top
Member: support-m
support-m Dec 14, 2022 at 12:04:52 (UTC)
Goto Top
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
Member: letstryandfindout
letstryandfindout Dec 14, 2022 updated at 12:18:04 (UTC)
Goto Top
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.
lan
dhcp
Member: em-pie
em-pie Dec 14, 2022 at 12:49:40 (UTC)
Goto Top
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
Member: support-m
support-m Dec 14, 2022 at 12:51:54 (UTC)
Goto Top
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?
Member: aqui
aqui Dec 14, 2022 updated at 12:55:01 (UTC)
Goto Top
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!
Member: letstryandfindout
letstryandfindout Dec 14, 2022 updated at 12:56:01 (UTC)
Goto Top
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.
Member: greaman
greaman Dec 14, 2022 at 13:01:13 (UTC)
Goto Top
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.
Member: Spirit-of-Eli
Spirit-of-Eli Dec 14, 2022 at 13:05:57 (UTC)
Goto Top
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
heart1
Member: aqui
aqui Dec 14, 2022 at 13:17:14 (UTC)
Goto Top
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!
Member: letstryandfindout
letstryandfindout Dec 15, 2022 at 09:08:54 (UTC)
Goto Top
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:
screenshot 2022-12-15 100722
Member: aqui
aqui Dec 15, 2022 updated at 09:32:28 (UTC)
Goto Top
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. face-sad
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. face-sad

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.
Member: letstryandfindout
letstryandfindout Dec 15, 2022 updated at 09:34:15 (UTC)
Goto Top
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
Member: aqui
aqui Dec 15, 2022 at 09:34:04 (UTC)
Goto Top
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???
Member: letstryandfindout
letstryandfindout Dec 15, 2022 updated at 09:36:01 (UTC)
Goto Top
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
Member: aqui
aqui Dec 15, 2022 updated at 09:42:00 (UTC)
Goto Top
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
Member: letstryandfindout
Solution letstryandfindout Dec 15, 2022 at 12:37:23 (UTC)
Goto Top
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.
Member: aqui
aqui Dec 15, 2022 at 15:24:26 (UTC)
Goto Top
👏👍 Eine schwere Geburt mit glücklichem Ausgang.
Bestätigt aber mal wieder die Annahme das es nicht an der FW gelegen hat!
heart1
Member: letstryandfindout
letstryandfindout Dec 16, 2022 at 14:30:29 (UTC)
Goto Top
Freut mich auch am Ende. Wenn man den schwarzen Peter dann von sich schieben kann. Schöne Festtage face-smile wünsche ich.
GermansolvedQuestionFirewall
Hotly discussed
admtechDeveloper diary: Release 6.1admtechDaniEnd of availability for classic Teams clientDani