13
OPNSense blockt Datenverkehr von intern über web zurück nach intern
Hey Leute.
Vor einem Jahr hatte ich hier bereits gefragt wie man über eine einzige Netzwerkschnittstelle eine Firewall in Proxmox realisiert bekommt.
HomeLAB Proxmox Firewall
Gestern habe ich mir ein neues WLAN gekauft und war mit der internen Portweiterleitung derart unzufrieden, dass ich mich nochmal mit dem Thema beschäftigt habe - hatte es aus Frust ruhen lassen und alles im Schrank verstaut...
Die Eingebung kam diesmal Recht schnell, so dass es quasi auf Anhieb lief.
Das WAN bekommt über den Switch ein Tag 10 und die Schnittstelle im proxmox ist VLAN Aware.
In der OPNSense VM gibt es nur eine Schnittstelle und innerhalb der VM wird zwischen eth0 und eth0.10 unterschieden, grob gesagt.
Jedenfalls funktioniert der Netzwerkfluss soweit sehr gut, die Geschwindigkeit stimmt und auch die ersten Portweiterleitungen funktionieren, zumindest von extern ins Heimnetz!
Allerdings kann ich nicht aus dem internen Netzwerk auf meine freigegebenen Dienste zugreifen, zb <http://DYNDNS.de:44444> bringt mich von außerhalb auf meinen Jellyfin-Server. Versuche ich dies jedoch aus dem internen Netz heraus, wird es blockiert bzw es gibt nur einen timeout.
Was muss ich hier beachten oder wonach muss ich in der Dokumentation suchen?
Vor einem Jahr hatte ich hier bereits gefragt wie man über eine einzige Netzwerkschnittstelle eine Firewall in Proxmox realisiert bekommt.
HomeLAB Proxmox Firewall
Gestern habe ich mir ein neues WLAN gekauft und war mit der internen Portweiterleitung derart unzufrieden, dass ich mich nochmal mit dem Thema beschäftigt habe - hatte es aus Frust ruhen lassen und alles im Schrank verstaut...
Die Eingebung kam diesmal Recht schnell, so dass es quasi auf Anhieb lief.
Das WAN bekommt über den Switch ein Tag 10 und die Schnittstelle im proxmox ist VLAN Aware.
In der OPNSense VM gibt es nur eine Schnittstelle und innerhalb der VM wird zwischen eth0 und eth0.10 unterschieden, grob gesagt.
Jedenfalls funktioniert der Netzwerkfluss soweit sehr gut, die Geschwindigkeit stimmt und auch die ersten Portweiterleitungen funktionieren, zumindest von extern ins Heimnetz!
Allerdings kann ich nicht aus dem internen Netzwerk auf meine freigegebenen Dienste zugreifen, zb <http://DYNDNS.de:44444> bringt mich von außerhalb auf meinen Jellyfin-Server. Versuche ich dies jedoch aus dem internen Netz heraus, wird es blockiert bzw es gibt nur einen timeout.
Was muss ich hier beachten oder wonach muss ich in der Dokumentation suchen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 31196272742
Url: https://administrator.de/forum/opnsense-blockt-datenverkehr-von-intern-ueber-web-zurueck-nach-intern-31196272742.html
Ausgedruckt am: 21.12.2024 um 16:12 Uhr
13 Kommentare
Neuester Kommentar
Und der zweite Kardinalsfehler ist mal wieder die alte Leier mit einer falschen, interne TLD!
Manche lernen es nie!
Hinweise zur Verwendung der Domäne .local in DNS und mDNS
https://imatrix.at/schlechter-domain-name/
Desweiteren:
Manche lernen es nie!
Hinweise zur Verwendung der Domäne .local in DNS und mDNS
https://imatrix.at/schlechter-domain-name/
Desweiteren:
- Wireguard Forwarding wo eine OPNsense selber Wireguard kann und jeder Netzwerker weiss das VPNs immer auf die Peripherie wie Firewall/Router etc. gehören?!
- Bei so einer löchrigen Firewall wie bei dir mit den ganzen Port Forwardings die dadurch ungeschützen Internet Traffic ins lokale Netz lassen und das gleich mehrfach, gehören solche Server immer in ein separates DMZ Segment aber niemals alle in das schützenswerte lokale LAN. Ein gutes und sinnvolles Firewall Design sieht bekanntlich anders aus. Aber egal....
Bei so einer löchrigen Firewall wie bei dir mit den ganzen Port Forwardings
Hilft nur ein VPN.
1
Ich habe das ganze gerade erst in Betrieb genommen, allwissend ist leider noch niemand vom Himmel gefallen.
- Das externe wireguard ist temporär, da es bisher nicht anders realisierbar war mit dem ehemaligen Aufbau -> wird künftig über die OPNs laufen.
- von der .local Problematik habe ich bisher auch noch nie etwas gehört und lief jahrelang problemfrei, nutze allerdings auch kein Bonjour/Apple. Werde es dennoch umstellen, danke für den Hinweis
Löchrige Firewall, nun ja... Wireguard wird umgestellt, Vikunja soll demnächst auch nur noch über VPN laufen und der Rest... Wie soll es anders gehen mit zb rustdesk?
Ich beschäftige mich demnächst eventuell nochmal mit Reverse Proxy, das hab ich bisher nicht klar verstanden.
Vergiss nicht dass ich keine Firma sondern privatperson bin (soll nicht heißen dass ich mich der ganzen Welt öffnen will. Hat schon seinen Sinn mit Firewall etc)
@Spirit-of-Eli danke, darüber bin ich bereits gestolpert, lag also nicht so verkehrt.
Warum funktioniert sowas bei zb einem herkömmlichen Netgear Router Out of the Box ohne weitere Konfiguration?
Werde mich dem heute Mittag direkt annehmen und probieren.
- Das externe wireguard ist temporär, da es bisher nicht anders realisierbar war mit dem ehemaligen Aufbau -> wird künftig über die OPNs laufen.
- von der .local Problematik habe ich bisher auch noch nie etwas gehört und lief jahrelang problemfrei, nutze allerdings auch kein Bonjour/Apple. Werde es dennoch umstellen, danke für den Hinweis
Löchrige Firewall, nun ja... Wireguard wird umgestellt, Vikunja soll demnächst auch nur noch über VPN laufen und der Rest... Wie soll es anders gehen mit zb rustdesk?
Ich beschäftige mich demnächst eventuell nochmal mit Reverse Proxy, das hab ich bisher nicht klar verstanden.
Vergiss nicht dass ich keine Firma sondern privatperson bin (soll nicht heißen dass ich mich der ganzen Welt öffnen will. Hat schon seinen Sinn mit Firewall etc)
@Spirit-of-Eli danke, darüber bin ich bereits gestolpert, lag also nicht so verkehrt.
Warum funktioniert sowas bei zb einem herkömmlichen Netgear Router Out of the Box ohne weitere Konfiguration?
Werde mich dem heute Mittag direkt annehmen und probieren.
Vergiss nicht dass ich keine Firma sondern privatperson bin
Ach, wenn das so ist. Die Bots, die die ganze Zeit alles im Internet nach Sicherheitslücken scannen, haben eine Fairnessregel, dass Privatpersonen nicht angegriffen werden.Warum funktioniert sowas bei zb einem herkömmlichen Netgear Router Out of the Box ohne weitere Konfiguration?
Das hat der Programmierer so designt. Bei manchen Netzwerkdesigns ist das auch gar nicht erwünscht, z.B., wenn der Mitarbeiter mit seinem VPN Tunnel keine Loops bauen können soll, wenn er aktuell mit seinem Laptop in der Firma sitzt.
Ja gut, Punkt für dich.
Ich habe für die Freigaben bewusst hohe Portzahlen gewählt die eher nicht so der Standard sind.
Wurden laut den Protokollen des alten Routers auch nie abgefragt - sofern man den Protokollen trauen darf.
Mit loops bin ich so bewusst noch nicht in Berührung gekommen.
Ich habe für die Freigaben bewusst hohe Portzahlen gewählt die eher nicht so der Standard sind.
Wurden laut den Protokollen des alten Routers auch nie abgefragt - sofern man den Protokollen trauen darf.
Mit loops bin ich so bewusst noch nicht in Berührung gekommen.
So weit so fein...
Habe nun folgendes gemacht:
- Domain auf ".internal" geändert
- Firewall / Settings / Advanced - Automatik outbound NAT for Reflection aktiviert
Die Port-Forward regel für Jellyfin folgendermaßen konfiguriert:
- Interface: LAN, WAN
- TCP/IP: Pv4
- Protocoll: TCP
- Dest.: WAN Adress
- Dest,-Port: 44444-44444
- Redirect target: 192.168.178.107
- Redirect targ. port: 8096
- NAT Reflection: Use System Default
So funktioniert schonmal das interne Verwenden von Jellyfin über die DynDNS-Freigabe.
Wireguard hab ich schon kurz umgestellt gehabt, hatte aber massive Probleme mit RDP....gibts hier was besonderes zu beachten? Laut Protokoll wirds erlaubt...
Hier nochmal das aktuelle Schema:
Habe nun folgendes gemacht:
- Domain auf ".internal" geändert
- Firewall / Settings / Advanced - Automatik outbound NAT for Reflection aktiviert
Die Port-Forward regel für Jellyfin folgendermaßen konfiguriert:
- Interface: LAN, WAN
- TCP/IP: Pv4
- Protocoll: TCP
- Dest.: WAN Adress
- Dest,-Port: 44444-44444
- Redirect target: 192.168.178.107
- Redirect targ. port: 8096
- NAT Reflection: Use System Default
So funktioniert schonmal das interne Verwenden von Jellyfin über die DynDNS-Freigabe.
Wireguard hab ich schon kurz umgestellt gehabt, hatte aber massive Probleme mit RDP....gibts hier was besonderes zu beachten? Laut Protokoll wirds erlaubt...
Hier nochmal das aktuelle Schema:
Na für Wireguard auf der Sense sind Firewall Regeln nötig.
am Interface hab ich die beliebte Any Any angewandt, was ja auch eigentlich in meinem Sinn ist... wenn ich mich einlogge will ich alles dürfen. Prinzipiell geht es, kann Geräte ansteuern und aufs NAS zugreifen, nur RDP geht nicht.
Wenn ich WG über die Portfreigabe nutze wie auf dem Schema zu sehen, kann ich alles machen... so lief es ja bislang auch seit mindestens einem Jahr
Wenn ich WG über die Portfreigabe nutze wie auf dem Schema zu sehen, kann ich alles machen... so lief es ja bislang auch seit mindestens einem Jahr
Dann fehlen die Regeln am Windows Client um das WG Netz zuzulassen.
also rein von der config-datei her ists es 1:1 identisch mit der config vom LXC.
Damit dürfte am Windows-Client eigentlich garnix zu ändern sein.
Es funktioniert auch vom Android-Smartphone nicht.
Ist die oben genannte Config vom outbound NAT so legitim?
Gibt es irgendwo ne Art Prüfablauf um zu checken, das alles sicher konfiguriert ist?
Klar, ich habe hier ned den Traum-Aufbau mit Hardware-Trennung und Netztrennung... so weit bin ich noch ned....Step by Step
Damit dürfte am Windows-Client eigentlich garnix zu ändern sein.
Es funktioniert auch vom Android-Smartphone nicht.
Ist die oben genannte Config vom outbound NAT so legitim?
Gibt es irgendwo ne Art Prüfablauf um zu checken, das alles sicher konfiguriert ist?
Klar, ich habe hier ned den Traum-Aufbau mit Hardware-Trennung und Netztrennung... so weit bin ich noch ned....Step by Step
Hallo,
Du kannst weiter träumen und den Spezis hier weiterhin nichtsglauben, dann weiterhin zeit vertrödeln und nix gescheites auf die Reihe kriegen. Dein Proxmox hat nur 1 NIC aber dafür 12 VMs. Aber dafür son unsinniges zeug wie
Deine Fragen kommen so rüber als wenn du einen Prüfdorn für 6,25 mm Bohrlöcher hast und nun auf suche bist warum der in dein Bohrloch vom 12 mm dir nix nutzt. Routing funktioniert nicht wenn alle im gleichen Netz sich befinden, ohne Routing hast du kein Internet oder Intranet oder kommunikation zu deiner TESLA Tankstelle... Und Windows kann sehr wohl unterscheiden und gezielt blockieren.
Und kannst du kein USB LAN Adapter nutzen oder einen zusätzliche Steckkarte oder ist das einfach zu teuer für dein Spieltrieb? Und Internet Hacker nehmen keine Rücksicht auf Kinder, die hacken alles wo die dran kommen, egal ob Ports geändert wurden. Selbst ein 6502 CPU aus z.B. Commodere C64 Kann schneller die Ports von 1 bis 65536 sowohl für TCP als auch für UDP (also 2 mal hintereinander zählen als du die Zal 1.000.000,00 aufschreiben kannst.
https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.htm ...
Gruss,
Peter
Du kannst weiter träumen und den Spezis hier weiterhin nichtsglauben, dann weiterhin zeit vertrödeln und nix gescheites auf die Reihe kriegen. Dein Proxmox hat nur 1 NIC aber dafür 12 VMs. Aber dafür son unsinniges zeug wie
Klar, ich habe hier ned den Traum-Aufbau mit Hardware-Trennung und Netztrennung... so weit bin ich noch ned....Step by Step
Mit zwei oder mehr NICs wären deine hausgemachten Probleme eben grösser und Koplexer. Nutze einen Wireshark auf dein Proxmox um zu sehen woher deine Pakete kommen und wohin die wollen- Dann wirst du höchszwahrscheinlich sehen das deine Windows Büchse doch fremde IPs sperrt. Ist lange schon der Normalzustand. Kabelhai RDP Abhorchen https://ask.wireshark.org/question/26012/how-to-convince-wireshark-to-in ...Es funktioniert auch vom Android-Smartphone nicht.
Gott sei dank, oder nichtIst die oben genannte Config vom outbound NAT so legitim?
Auch das kann dir der Kabelhai sagen...Gibt es irgendwo ne Art Prüfablauf um zu checken, das alles sicher konfiguriert ist?
Was soll denn geprüft werden und nach welchen Regeln / Normierungen?. Überlege noch einmal.Deine Fragen kommen so rüber als wenn du einen Prüfdorn für 6,25 mm Bohrlöcher hast und nun auf suche bist warum der in dein Bohrloch vom 12 mm dir nix nutzt. Routing funktioniert nicht wenn alle im gleichen Netz sich befinden, ohne Routing hast du kein Internet oder Intranet oder kommunikation zu deiner TESLA Tankstelle... Und Windows kann sehr wohl unterscheiden und gezielt blockieren.
Und kannst du kein USB LAN Adapter nutzen oder einen zusätzliche Steckkarte oder ist das einfach zu teuer für dein Spieltrieb? Und Internet Hacker nehmen keine Rücksicht auf Kinder, die hacken alles wo die dran kommen, egal ob Ports geändert wurden. Selbst ein 6502 CPU aus z.B. Commodere C64 Kann schneller die Ports von 1 bis 65536 sowohl für TCP als auch für UDP (also 2 mal hintereinander zählen als du die Zal 1.000.000,00 aufschreiben kannst.
https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.htm ...
Gruss,
Peter
Jetzt bitte nicht so von oben herab...
Wie gesagt, bin mehr oder weniger neu in dem Thema und lernbereit - meine eigentlichen Fähigkeiten liegen halt eher in Mechanik (Auto, Zerspanung etc..)
Versuche mir die Sachen schon richtig anzueignen und umzusetzen - bin halt kein Mr Hawkins.
Die ganze virtuellen Maschinen bzw LXCs haben schon ihre Daseinsberechtigung - aus meiner Sicht.
Das Windows ebenfalls seine Regeln hat ist mir auch durchaus klar - werde dahingehend nochmal schauen und auch wireshark unter die Lupe nehmen.
Zusätzliche Steckkarte ist bei der Hardware leider nicht machbar (Lenovo tiny) und über USB LAN hatte ich damals nachgedacht, mich dann aber fürs VLAN per managed Switch entschieden.
Wie gesagt, bin mehr oder weniger neu in dem Thema und lernbereit - meine eigentlichen Fähigkeiten liegen halt eher in Mechanik (Auto, Zerspanung etc..)
Versuche mir die Sachen schon richtig anzueignen und umzusetzen - bin halt kein Mr Hawkins.
Die ganze virtuellen Maschinen bzw LXCs haben schon ihre Daseinsberechtigung - aus meiner Sicht.
Das Windows ebenfalls seine Regeln hat ist mir auch durchaus klar - werde dahingehend nochmal schauen und auch wireshark unter die Lupe nehmen.
Zusätzliche Steckkarte ist bei der Hardware leider nicht machbar (Lenovo tiny) und über USB LAN hatte ich damals nachgedacht, mich dann aber fürs VLAN per managed Switch entschieden.
