Umbau FritzBox Netzwerk auf OpnSense
- Ersteller fmeyer84
- Erstellt am
blurrrr
Well-known member
1. Vermutung: Willkommen in der Welt von "NAT". Das ist genau das, was Du (rein intern) eben nicht willst. Sofern Du auf der Fritz!Box für alle Netze hinter der OPNsense eine entsprechende Route angelegt hast, brauchst Du kein NAT (das ist nur sinnvoll beim Übergang ins Internet, also macht die Fritz!Box das).
Das "Problem" was Du nun vermutlich hast: Du sagst, dass Du die IP vom PC eingetragen hast. Dies wäre z.B. die 192.168.2.100. Wenn NAT aktiviert ist, kommst Du bei Deiner Syno aber nicht mit der IP Deines PCs an, sondern mit der WAN-IP der Firewall. Stell das mal um auf manuell oder deaktiviert:
Man kann es auch auf manuell stellen, falls man doch mal die ein oder andere Regel braucht. Ich habe es bei mir immer auf manuell stehen und wenn nichts benötigt wird, dann ist halt auch nichts drin. Ein möglicher Grund könnte z.B. ein Gerät sein, welches kein Gateway hat und nur mit Teilnehmern im eigenen Netz sprechen kann. Wenn man dann aus einem anderen Netz kommt, können die beiden nicht miteinander kommunizieren, sowas könnte z.B. ein Grund für für ein manuelles NAT sein, aber da besteht derzeit für Dich kein Bedarf - also weg damit
blurrrr
Well-known member
Kleiner Nachtrag: Soviel über NAT geschrieben, aber garnicht erklärt, was es macht... sorry! 
Das holen wir nun kurz nach:
In seiner - bei SOHO-Netzwerken - am häufigsten auftretenden Art handelt es sich um ein SNAT (Source-NAT / Quell-NAT). Dabei geht es um folgendes: Ein Gerät (i.d.R. eine Firewall, oder eben ein Router) stellt interne Netzwerke aus einem "privaten" IP-Adressbereich für interne Geräte zur Verfügung. Hängt man seinen PC z.B. an eine standardmässig konfigurierte Fritz!Box, so erhält der PC eine IP aus dem Adressbereich 192.168.178.0/24. Dies ist ein privater Adressbereich und private Adressbereiche werden im Internet nicht weitergeleitet. Das kann auch nicht funktionieren, da (beispielhaft) jeder Besitzer einer Fritz!Box dann mit einer IP aus dem Netz 192.168.178.0/24 im Internet unterwegs wäre und "extern" nicht wüsste, wer jetzt eigentlich der richtige Empfänger wäre. Also private Netze im Internet, keine Chance. Da kommt nun NAT (Network Address Translation) ins Spiel, bzw. in diesem Fall etwas konkreter "SNAT" (Source-NAT/Quell-NAT). Es verändert die Quell-IP eines Paketes. Schickt man vom PC (z.B. hinter Deiner OPNsense) ein Paket los...
Quell-IP: 192.168.2.100
Ziel-IP: 8.8.8.8
Passiert - bei Deinem aktuellen Konstrukt nun folgendes:
Paket-Status PC:
Quell-IP: 192.168.2.100
Ziel-IP: 8.8.8.8
Paket-Status OPNsense:
Quell-IP: 192.168.1.254 (SNAT)
Ziel-IP: 8.8.8.8
Paket-Status Fritz!Box:
Quell-IP: <öffentliche IP der Fritz!Box> (SNAT)
Ziel-IP: 8.8.8.8
Heisst also für die OPNsense bei standardmässig aktiviertem (S)NAT, dass alle Pakete, welche von den internen Netzen der OPNsense ins Netz der Fritz!Box kommen, eben über das WAN-Interface der OPNsense mit der WAN-IP der OPNsense im Fritz!Box-Netzwerk auftauchen. Das kannst Du auch ganz leicht überprüfen: Melde Dich vom PC hinter der OPNsense bei der Fritz!Box an und schau dort mal in die Logs der Fritz!Box bzgl. Deines grade stattgefundenen Logins auf der Fritz!Box. Dort sollte die IP aufgelistet sein, von welcher Du Dich bei der Fritz!Box angemeldet hast. Sieht dann so aus:
Also in Deinem "privaten" Netzwerk ist NAT weder schön, noch förderlich, also will man sowas zwischen seinen internen Netzen auch garnicht haben.
Als kleiner - auch häufig auftretender - Gegenspieler dazu gäbe es noch das DNAT (Destination-NAT / Ziel-NAT). Es gibt noch mehr, aber die sind erstmal nicht relevant. DNAT hat Du bestimmt schon eingesetzt, sogar ziemlich sicher. Es geht also um die "Ziel"-IP in einem Paket.
Die Fritz!Box vereint "zwei" Dinge mit ihren "Portfreigaben". Zum einen eine DNAT-Regel, zum anderen auch eine Firewall-Regel (das ist wichtig zu wissen, wenn man sich nun mit Firewall-Systemen befasst), es sind also 2 Konfigurationen, welche zusammenpassen müssen.
Zum einen gehst Du hin und machst ein DNAT in Form von: Wenn ein Paket an der öffentlichen IP vom System und für Port 5678 ankommt, dann leite es weiter zur internen IP 192.168.178.100 (und verändere den Zielport ggf. noch auf 443). Das wäre halt so eine "typische" Portweiterleitung (in Form eines DNAT). Weil das nun nicht reicht, muss natürlich auch noch eine entsprechende Firewall-Regel erstellt werden, ansonsten ist zwar die Anweisung für die Transformation des Paket-Headers gegeben (IP und ggf. Port umschreiben), aber wenn die Firewall nein sagt, bleibt es halt beim nein.
Das nur mal als kleinen Ausflug in die NAT-Welt, mit welcher Du hoffentlich nur auf Deinem Internet-Router in Berührung kommst. Mit IPv6 fällt NAT eigentlich komplett weg, weil i.d.R. sowieso jedes System seine eigene öffentliche IP bekommt (bzw. bekommen sollte). Da gibt es dann also nur noch Firewall-Regeln. Ist nicht so, als gäbe es gar kein NAT mehr unter IPv6, aber die Notwendigkeit ist i.d.R. eben nicht mehr gegeben. Gibt sicherlich noch Fälle, wo sowas zum Einsatz kommt, aber im privaten Bereich denke ich eher nicht, da wird es primär beim ganz normalen Routing und entsprechenden Firewall-Regeln bleiben (ist also eigentlich sogar einfacher als IPv4, wenn man von der Hexadezimal-Schreibweise von IPv6 mal absieht
).
Das holen wir nun kurz nach:In seiner - bei SOHO-Netzwerken - am häufigsten auftretenden Art handelt es sich um ein SNAT (Source-NAT / Quell-NAT). Dabei geht es um folgendes: Ein Gerät (i.d.R. eine Firewall, oder eben ein Router) stellt interne Netzwerke aus einem "privaten" IP-Adressbereich für interne Geräte zur Verfügung. Hängt man seinen PC z.B. an eine standardmässig konfigurierte Fritz!Box, so erhält der PC eine IP aus dem Adressbereich 192.168.178.0/24. Dies ist ein privater Adressbereich und private Adressbereiche werden im Internet nicht weitergeleitet. Das kann auch nicht funktionieren, da (beispielhaft) jeder Besitzer einer Fritz!Box dann mit einer IP aus dem Netz 192.168.178.0/24 im Internet unterwegs wäre und "extern" nicht wüsste, wer jetzt eigentlich der richtige Empfänger wäre. Also private Netze im Internet, keine Chance. Da kommt nun NAT (Network Address Translation) ins Spiel, bzw. in diesem Fall etwas konkreter "SNAT" (Source-NAT/Quell-NAT). Es verändert die Quell-IP eines Paketes. Schickt man vom PC (z.B. hinter Deiner OPNsense) ein Paket los...
Quell-IP: 192.168.2.100
Ziel-IP: 8.8.8.8
Passiert - bei Deinem aktuellen Konstrukt nun folgendes:
Paket-Status PC:
Quell-IP: 192.168.2.100
Ziel-IP: 8.8.8.8
Paket-Status OPNsense:
Quell-IP: 192.168.1.254 (SNAT)
Ziel-IP: 8.8.8.8
Paket-Status Fritz!Box:
Quell-IP: <öffentliche IP der Fritz!Box> (SNAT)
Ziel-IP: 8.8.8.8
Heisst also für die OPNsense bei standardmässig aktiviertem (S)NAT, dass alle Pakete, welche von den internen Netzen der OPNsense ins Netz der Fritz!Box kommen, eben über das WAN-Interface der OPNsense mit der WAN-IP der OPNsense im Fritz!Box-Netzwerk auftauchen. Das kannst Du auch ganz leicht überprüfen: Melde Dich vom PC hinter der OPNsense bei der Fritz!Box an und schau dort mal in die Logs der Fritz!Box bzgl. Deines grade stattgefundenen Logins auf der Fritz!Box. Dort sollte die IP aufgelistet sein, von welcher Du Dich bei der Fritz!Box angemeldet hast. Sieht dann so aus:
Also in Deinem "privaten" Netzwerk ist NAT weder schön, noch förderlich, also will man sowas zwischen seinen internen Netzen auch garnicht haben.
Als kleiner - auch häufig auftretender - Gegenspieler dazu gäbe es noch das DNAT (Destination-NAT / Ziel-NAT). Es gibt noch mehr, aber die sind erstmal nicht relevant. DNAT hat Du bestimmt schon eingesetzt, sogar ziemlich sicher. Es geht also um die "Ziel"-IP in einem Paket.
Die Fritz!Box vereint "zwei" Dinge mit ihren "Portfreigaben". Zum einen eine DNAT-Regel, zum anderen auch eine Firewall-Regel (das ist wichtig zu wissen, wenn man sich nun mit Firewall-Systemen befasst), es sind also 2 Konfigurationen, welche zusammenpassen müssen.
Zum einen gehst Du hin und machst ein DNAT in Form von: Wenn ein Paket an der öffentlichen IP vom System und für Port 5678 ankommt, dann leite es weiter zur internen IP 192.168.178.100 (und verändere den Zielport ggf. noch auf 443). Das wäre halt so eine "typische" Portweiterleitung (in Form eines DNAT). Weil das nun nicht reicht, muss natürlich auch noch eine entsprechende Firewall-Regel erstellt werden, ansonsten ist zwar die Anweisung für die Transformation des Paket-Headers gegeben (IP und ggf. Port umschreiben), aber wenn die Firewall nein sagt, bleibt es halt beim nein.
Das nur mal als kleinen Ausflug in die NAT-Welt, mit welcher Du hoffentlich nur auf Deinem Internet-Router in Berührung kommst. Mit IPv6 fällt NAT eigentlich komplett weg, weil i.d.R. sowieso jedes System seine eigene öffentliche IP bekommt (bzw. bekommen sollte). Da gibt es dann also nur noch Firewall-Regeln. Ist nicht so, als gäbe es gar kein NAT mehr unter IPv6, aber die Notwendigkeit ist i.d.R. eben nicht mehr gegeben. Gibt sicherlich noch Fälle, wo sowas zum Einsatz kommt, aber im privaten Bereich denke ich eher nicht, da wird es primär beim ganz normalen Routing und entsprechenden Firewall-Regeln bleiben (ist also eigentlich sogar einfacher als IPv4, wenn man von der Hexadezimal-Schreibweise von IPv6 mal absieht
).Genau das war der Punkt, jetzt geht es. ich hatte ich mich in den Firewall-Live-Logs schon gewundert warum die 192.168.1.254 (WAN Sense) die Syno (192.168.1.2) auf dem Port 3493 will. Aber so macht das natürlich Sinn.
Was mich aber wundert: Ich habe jetzt mal die von mir in https://forum.heimnetz.de/threads/umbau-fritzbox-netzwerk-auf-opnsense.8568/page-2#post-84212 hinterlegte WAN Regel rausgenommen und die Verbindung klappt trotzdem noch...
Was mich aber wundert: Ich habe jetzt mal die von mir in https://forum.heimnetz.de/threads/umbau-fritzbox-netzwerk-auf-opnsense.8568/page-2#post-84212 hinterlegte WAN Regel rausgenommen und die Verbindung klappt trotzdem noch...
blurrrr
Well-known member
Naja, die Frage ist erstmal: Wie läuft der Verbindungsaufbau (Quelle -> Ziel)? Das ist ein Punkt, welchen man bei Firewall-Regeln "immer" berücksichtigen muss. "Antworten" dürfen i.d.R. immer zurück, die primäre Frage ist immer von wo nach wo der intiale Verbindungsaufbau stattfindet. Fragt der PC bzw. NUT-Client beim Server nach, oder schickt der Server einfach initial eine Nachricht an den Client? Um das jetzt mal abzukürzen: Hast Du irgendwo auf dem NUT-Server gesagt, welche Clients aktiv benachrichtigt werden sollen? Ich denke nicht (wäre mir jedenfalls nicht bekannt).
Insofern bleibt auch nur eine einzige Schlussfolgerung: Der Client nimmt eigenständig Kontakt mit dem Server auf, somit initiiert der Client die Verbindung, nicht der Server:
Somit sollte sich die Regel bzgl. der Verbindung "von" der Syno "zum" Client eigentlich sowieso erledigt haben, da die Syno nicht initial die Verbindung zum PC aufbaut.
Insofern bleibt auch nur eine einzige Schlussfolgerung: Der Client nimmt eigenständig Kontakt mit dem Server auf, somit initiiert der Client die Verbindung, nicht der Server:
(Quelle: https://networkupstools.org/docs/man/upsd.html)
(Quelle: https://networkupstools.org/docs/man/upsc.html)
Somit sollte sich die Regel bzgl. der Verbindung "von" der Syno "zum" Client eigentlich sowieso erledigt haben, da die Syno nicht initial die Verbindung zum PC aufbaut.
Ok verstanden, ich hab ja im USV Server in der Synology die erlaubten IP Adressen hinterlegt. Ich muss das mal testen, wenn die USV in den Akku Modus, ob dann alles sauber herunterfährt am PC, so war bisher immer im lokalen FritzBox Netz.
BTW: mit deaktivierten NAT kommen die Clients aus meinem WLAN (192.168.3.x) nicht mehr ins Internet. Aktiviere ich das wieder, geht Internet.
BTW: mit deaktivierten NAT kommen die Clients aus meinem WLAN (192.168.3.x) nicht mehr ins Internet. Aktiviere ich das wieder, geht Internet.
blurrrr
Well-known member
Das sieht sehr nach einem ganz bestimmten Szenario aus... Wenn man den Rückweg nicht kennt, sieht es auch eher mau aus, wenn man eine Antwort erhalten möchte:
Anfrage ausgehend: Client schickt Anfrage, OPNsense leitet weiter an Fritz!Box, Fritz!Box leitet weiter ins Internet.
Antwort eingehend: Anfrage kommt wieder an der Fritz!Box an, Fritz!Box hat keine Ahnung, wie sie die Ziel-IP erreichen kann und leitet das Paket weiter an Ihr Standard-Gateway (wieder Richtung Internet, wo das Paket dann verworfen wird).
Was fehlt?
(Tip: Hat vermutlich etwas mit der Fritz!Box zu tun)