Neuling - Hilfe beim Routing zwischen zwei Subnetzen (WAN und LAN)

saveLAN

Member
Hallo,

kann mir vielleicht jemand helfen wie ich in meinem Testaufbau mit der OPNsense ein Routing zwischen zwei Subnetzen realisiere.
Da es ein Testaufbau ist, soll das NAT auf der Sense aktiv bleiben um den späteren Betrieb möglichst detailgetreu abzubilden.

Aktuell ist der Aufbau folgender:

Fritz-Box (192.168.178.1): LAN1 ====> WAN (OPNsense IP 192.178.168.3 per Fritz-DHCP)

OPNsense LAN hat das Subnetz 192.168.1.1. Hier hängt dann ein Switch.

Ich habe es bisher per Firewall-Regel geschafft, dass ich mit einem Rechner aus dem Fritz-Netz 192.168.178.1/24 über das WAN auf das Webinterface der Sense (192.178.168.3) komme.
Allerdings würde ich gerne von dem Rechner aus dem Fritz Netz auf den Switch im Sense-LAN 192.168.1.1/24 zugreifen. Hier wäre ein Routing notwendig!

Ich habe schon alles mögliche beim Routing und Gateway ausprobiert, aber ich komme nicht weiter.
Kann mir vielleicht jemand einen Tipp geben, wie ich das in meinem Testaufbau realisieren könnte?
 
Hi :)

Allerdings würde ich gerne von dem Rechner aus dem Fritz Netz auf den Switch im Sense-LAN 192.168.1.1/24 zugreifen
soll das NAT auf der Sense aktiv bleiben
Computer sagt: "Nein." 🙃

Wenn Du mit NAT arbeitest (pfSense-Netz -> SNAT -> extern (dazu gehört auch das Fritzbox-Netz), wird das so nicht funktionieren. Das "warum" ist relativ einfach (beispielhaft) erklärt:

192.168.178.100 (anfragender Client)
192.168.1.100 (Ziel des anfragenden Clients)

192.168.178.100 fragt 192.168.1.100 nach irgendwas und erwartet auch die Antwort von? Richtig.... der 192.168.1.100. Jut, also Anfrage ist raus, 192.168.1.100 antwortet nun und schickt die Antwort an die 192.168.178.100. Die Antwort muss allerdings durch die pfSense und die hat die Anweisung, alles was vom pfSense-LAN (192.168.1.0/24)nach draussen geht, entsprechend mit ihrer eigenen WAN-IP zu maskieren (192.168.178.3). Nun erhält der Client 192.168.178.100 eine Antwort von 192.168.178.3, verwirft die aber sofort, weil ... neeee.... mit dem Ding hat er ja garnicht geredet!.... und wartet weiterhin auf die Antwort von 192.168.1.100, welche aber nie kommen wird.... irgendwann merkt der Client das auch und das ganze endet mit einem Timeout.

Was das hier angeht:
Hier wäre ein Routing notwendig!
Das ist eigentlich "immer" notwendig, sobald es über Netz-Grenzen hinweg geht :)
 
Wenn Du mit NAT arbeitest (pfSense-Netz -> SNAT -> extern (dazu gehört auch das Fritzbox-Netz), wird das so nicht funktionieren. Das "warum" ist relativ einfach (beispielhaft) erklärt:

192.168.178.100 (anfragender Client)
192.168.1.100 (Ziel des anfragenden Clients)

192.168.178.100 fragt 192.168.1.100 nach irgendwas und erwartet auch die Antwort von? Richtig.... der 192.168.1.100. Jut, also Anfrage ist raus, 192.168.1.100 antwortet nun und schickt die Antwort an die 192.168.178.100. Die Antwort muss allerdings durch die pfSense und die hat die Anweisung, alles was vom pfSense-LAN (192.168.1.0/24)nach draussen geht, entsprechend mit ihrer eigenen WAN-IP zu maskieren (192.168.178.3). Nun erhält der Client 192.168.178.100 eine Antwort von 192.168.178.3, verwirft die aber sofort, weil ... neeee.... mit dem Ding hat er ja garnicht geredet!.... und wartet weiterhin auf die Antwort von 192.168.1.100, welche aber nie kommen wird.... irgendwann merkt der Client das auch und das ganze endet mit einem Timeout.
Danke dir. Das war sehr anschaulich. Und jetzt verstehe ich das Problem.

Das heißt was im LAN hinter der Sense als Routing läuft funktioniert, weil nicht maskiert wird und die angefragte IP auch antwortet, auch wenn die Antwort noch in ein anderes Subnetz geroutet wird?
Daher auch nie verscheide Subnetze mit gleichen IP-Bereichen, weil es sonst jetzt krachen würde?
Durch das NAT wird allerdings immer die "WAN-IP" der Sense antworten und nach der war nicht gefragt! ;)

Heißt als Konsequenz entweder das NAT in der Sense ausschalten oder auf so etwas verzichten?
Bzw. gleich den anfragenden Rechner in das LAN der Sense hängen! :)
 
Moinsen,
Ohne zu wissen, wie du dein heimnetz aufbauen und betreiben willst, kann zu

Heißt als Konsequenz entweder das NAT in der Sense ausschalten oder auf so etwas verzichten?
Bzw. gleich den anfragenden Rechner in das LAN der Sense hängen
nicht wirklich was gesagt werden.
Ich mache das für mich hier mit folgendem Aufbau:
Fritzbox als erster Router baut ihr LAN auf. Das WAN interface der pfsense bekommt eine feste IPvon der fritzbox.
Die pfsense macht NAT, es gibt eine Portweiterleitung für VPN. Sonst kommt gemäß NAT und Regeln auf dem WAN Interface nix rein.
Ich behandele also das LAN der fritzbox für mein eigentliches Heimnetz wie WAN. Da soll nix durch.
Die pfsense routet dann das eigentliche Netzwerk, organisiert die vlans, das übliche wie dns, dhcp, ntp usw.

Damit habe ich eine dmz VOR der pfsense, auf die ich vom Heimnetz HINTER der pfsense zugreifen kann aber eben nicht andersherum. Und das ist EIN Grund, warum das für meine Bedürfnisse so läuft.
:)
 
Damit habe ich eine dmz VOR der pfsense, auf die ich vom Heimnetz HINTER der pfsense zugreifen kann aber eben nicht andersherum. Und das ist EIN Grund, warum das für meine Bedürfnisse so läuft.
Genauso habe ich es ja eigentlich aktuell auch.
Mein Server hängt an der Fritzbox und somit in einer Art DMZ aus sicht des Sense-Netzes.
Dachte nur es wäre einfacher vom Server (VMs) in die Netze der Sense zu kommen.
Aber durch die Erklärung habe ich verstanden, dass das nicht geht.

Den Server in die Sense umziehen mag ich noch nicht, weil ich noch im Testen bin. Aber was solls, muss ich mir jetzt anderweitig helfen.
Wichtig ist ich habe dank euch wider viel gelernt, weil ich jetzt weiß warum es nicht geht.

Hast du eigentlich bisher dann Probleme durch das doppelte NAT feststellen können oder ist das problemlos?
 
Moinsen,
Ich selber habe mit doppelt NAT bislang kein Problem. Solange ein, zwei Dinge bedacht werden, läuft das.
Du kannst natürlich auch das NAT der pfsense ausstellen und auf dem wan interface mit manuellen regeln arbeiten...
Bietet der Server denn nach außen offene Dienste an...?
 
Bzw. gleich den anfragenden Rechner in das LAN der Sense hängen! :)
Das wäre das einfachste ;)

Heißt als Konsequenz entweder das NAT in der Sense ausschalten oder auf so etwas verzichten?
Ein "NAT" brauchst Du innerhalb Deiner eigenen Infrastruktur eigentlich nur an genau "einem einzigen" Punkt (und das auch nur bei IPv4) und das wäre der Übergang ins Internet. Da die Fritzbox das schon für Dich übernimmt, brauchst Du es also noch nichtmals irgendwo einschalten. Es wäre dann allerdings hilfreich, wenn Du der Fritzbox statische Routen für die Netze hinter der pfSense hinterlegst, so dass die Fritzbox auch den Weg dorthin kennt, denn ansonsten heisst es:

Anfrage kommt von pfSense-Client 192.168.1.100, geht weiter zur Fritzbox 192.168.178.1, geht weiter ins Internet - irgendwann kommt die Antwort zurück - Fritzbox bekommt die Antwort, will sie zur 192.168.1.100 schicken, aber sie kennt den Weg nicht! .... ein Teufelskreis... 😁 Statische Routen kannst Du bei der Fritzbox dort hinterlegen, wo Du auch die IP der Fritzbox ändern kannst:

1674597737307.png

Netzwerk = ein Netzwerk hinter der pfSense (z.B. 192.168.1.0)
Subnetzmaske: wie Du es angelegt hast (z.B. 255.255.255.0)
Gateway: WAN-IP(!) der pfSense (z.B. 192.168.178.3), das Gateway muss für die Fritzbox "direkt" erreichbar sein

Mein Server hängt an der Fritzbox und somit in einer Art DMZ aus sicht des Sense-Netzes.
Kann man machen, ich bevorzuge es eher, dass eine DMZ auch direkt über die Firewall abgewickelt wird, denn nur dort hat man auch vernünftige Steuerungs- und Kontrollmöglichkeiten.

Dachte nur es wäre einfacher vom Server (VMs) in die Netze der Sense zu kommen.
Das macht so "gar keinen" Sinn... Schau: Was Du da derzeit hast, könnte man - irgendwie/irgendwo - als 2-stufiges Firewall-Konzept betrachten. Dazwischen liegt die DMZ. Aus einer DMZ wird man "niemals" (<hier stehen jetzt ganz viele Ausrufezeichen ;)>) auf Netze hinter der zweiten Firewall zugreifen dürfen, da es das gesamte Konstrukt völlig ad absurdum führen würde. Sinn und Zweck einer DMZ ist es, dass "beide Parteien" (WAN+LAN) darauf zugreifen können. Im Endeffekt kann man sich das so vorstellen:

WAN -> DMZ <- LAN

Aus dem WAN heraus, "muss" natürlich ein Weg "hinein" führen. Bei IPv4 wäre es eine Portweiterleitung + Firewall-Regel, bei IPv6 eben nur eine Firewall-Regel (Portweiterleitung nur bei IPv4). Heisst für die WAN-Seite "musst" Du auch aktiv werden und in der Fritzbox eine Portweiterleitung/-freigabe einrichten (bei der Fritzbox ist es übrigens direkt "beides" - Weiterleitung + Regel, bei der pfSense ist sowas getrennt, wird aber i.d.R. automatisch beides mit der Anlage einer NAT-Regel erstellt). Aus der "LAN"-Sicht ist das Problem schon längst gelöst, da die pfSense eine Regel erstellt hat, dass man aus dem LAN halt in Richtung WAN darf ("WAN" ist hier aus Sicht der pfSense dann das Fritzbox-Netzwerk und alles dahinter (Internet)).

Grundsätzlich heisst es auch immer: Wenn etwas von innen (LAN) angefragt wurde, darf die Antwort von aussen (WAN) auch wieder rein. Deswegen funktioniert Dein Internet über die Fritzbox (und pfSense). Heisst also unter'm Strich, dass Du Dich bzgl. Gerätschaften in einer DMZ (wie in Deinem Konstrukt) nur um den Zugriff von aussen kümmern musst.

Wäre die DMZ jetzt über die pfSense verwaltet, müsstest Du dort für andere Netze entsprechende Zugriffsregeln erstellen. So ist die DMZ aber einfach nur "irgendwo WAN-seitig" und die pfSense interessiert sich auch nicht wirklich dafür. Den Zugriff für Teilnehmer hinter der pfSense kannst Du natürlich auch noch weiterhin einschränken durch Firewall-Regeln.

Soweit erstmal... ein Wort noch zu jenem hier:
Hast du eigentlich bisher dann Probleme durch das doppelte NAT feststellen können oder ist das problemlos?
Probleme wirst Du spätestens beim Thema VoIP bekommen, wenn das hinter der pfSense terminiert. Solange das bei Dir einfach nur über die Fritzbox läuft, ist es egal. Vielleicht liest Du Dich auch einfach mal in das Thema NAT ein, schaden wird es definitiv nicht, besonders dann nicht, wenn es ggf. doch mal für irgendwas (was auch immer) benötigt wird. Interessant wären da zumindestens mal einfach nur die 3 Begrifflichkeiten SNAT (Source-NAT), DNAT (Destination-NAT) und 1:1 NAT. Die ersten beiden kennst Du übrigens schon... SNAT ist typischerweise das, was Dein Router/die pfSense grade schon macht - nimm das innere Netz (Source) und wenn es raus will, überschreib die interne IP mit der WAN-IP der Fritzbox/pfSense. DNAT wäre dann die typische Portweiterleitung: Wenn etwas an Zie-IP xy ankommt (z.B. WAN-IP Fritzbox), nimm das Paket und schreib die Ziel-IP in eine interne IP um (z.B. interne Server-IP).

Also eigentlich.... alles schon mal irgendwie/irgendwo gesehen/gehört/gelesen ☺️

EDIT: @the other: Warum macht Deine pfSense noch NAT? Brauchst Du doch garnicht? Routen in der Fritzbox eintragen, NAT abschalten, fertig - damit ist der Drops schon gelutscht - da hatten auch andere schon das große Zittern, geht aber ohne Probleme. Routen eintragen kostet erstmal nix und ist bei "NAT an" auch erstmal völlig egal und dann einfach mal testweise NAT auf der pfSense abschalten und schauen, ob noch alles funktioniert - wenn nicht, schnell wieder einschalten und alles ist wieder gut! 😁
 
Zuletzt bearbeitet:
Anfrage kommt von pfSense-Client 192.168.1.100, geht weiter zur Fritzbox 192.168.178.1, geht weiter ins Internet - irgendwann kommt die Antwort zurück - Fritzbox bekommt die Antwort, will sie zur 192.168.1.100 schicken, aber sie kennt den Weg nicht! .... ein Teufelskreis... 😁
Das heißt, dass es bisher ohne statische Route funktioniert hat war eigentlich Glück und die Latenz war dadurch wesentlich höher?

Und nochmals hätte ich eine Frage zum Routing und den Subnetzen.
Geplante IP-Subnetze:
  • 192.168.178.1/24: Fritzbox (192.168.178.1) & WAN OPNsense (192.168.178.3)
  • Trunk-Port zu VLAN-Switch:
    • 192.168.10.1/24: VLAN10; DHCP-Bereich 192.168.10.100-192.168.10.199
    • 192.168.20.1/24: VLAN20; DHCP-Bereich 192.168.20.100-192.168.20.199
    • 192.168.30.1/24: VLAN30; DHCP-Bereich 192.168.30.100-192.168.30.199
    • 192.168.40.1/24: VLAN40; DHCP-Bereich 192.168.40.100-192.168.40.199
Wäre das soweit sinnvoll oder ein grober Denkfehler?
Oft lese ich auch, dass man bei den Klasse C Subnetzen an dritter Stelle ungerade Nummern wählen sollte also z.B. 192.168.21.1/24. Nur was ist der Hintergrund davon?
Was ich verstehe ist, dass man keine Subnetze von Standard-Routern oder APs nimmt, weil man sonst beim VPN-Zugang einen IP-Konflikt bekommen könnte.

Zum IP Konflikt hätte ich noch eine Frage.
Könnte ich bei den VLANs in der Theorie auch ein Subnetz verwenden, wenn ich penibel darauf achte, dass IPs keinesfalls doppelt vorkommen beim Routen zwischen den Netzen.
Also z.B.
  • Trunk-Port zu VLAN-Switch:
    • 192.168.10.1/24: VLAN10; DHCP-Bereich 192.168.10.100-192.168.10.120
    • 192.168.10.2/24: VLAN20; DHCP-Bereich 192.168.10.121-192.168.10.140
    • 192.168.10.3/24: VLAN30; DHCP-Bereich 192.168.10.141-192.168.10.160
    • 192.168.10.4/24: VLAN40; DHCP-Bereich 192.168.10.161-192.168.10.180
Mir ist klar, dass das überhaupt keinen Sinn macht, aber interessieren würde es mich, ob es generell funktionieren würde?
 
Das heißt, dass es bisher ohne statische Route funktioniert hat war eigentlich Glück und die Latenz war dadurch wesentlich höher?
"Glück" gibt es da "nicht" 😁 Funktioniert hat das ganze bisher aus folgendem Grund:

192.168.1.100 -> NAT (Umwandlung von 192.168.1.100 zu 192.168.178.3) -> Fritzbox-Netz

Pakete innerhalb eines Netzsegments brauchen keinen Router, sondern können "direkt" miteinander sprechen. Da in diesem Fall der pfSense-LAN-Client im Fritzbox-Netz mit der WAN-IP der pfSense erscheint, können die Fritzbox-Netz-Teilnehmer die Antwort "direkt" an die WAN-IP der pfSense schicken, welche die Antwort wieder dem pfSense-LAN-Client zuordnet (mittels NAT-Tabelle).
Wäre das soweit sinnvoll oder ein grober Denkfehler?
Kannste schon so machen.

Oft lese ich auch, dass man bei den Klasse C Subnetzen an dritter Stelle ungerade Nummern wählen sollte also z.B. 192.168.21.1/24. Nur was ist der Hintergrund davon?
Wer sagt denn bitte sowas? Das macht weder Sinn, noch wird es einen sinnvollen Hintergrund haben. Das mag man sich vllt irgendwo einreden, aber faktisch gibt es da nicht wirklich etwas sinnvolles hinter - also vergiss das ganz schnell wieder ☺️

Was ich verstehe ist, dass man keine Subnetze von Standard-Routern oder APs nimmt, weil man sonst beim VPN-Zugang einen IP-Konflikt bekommen könnte.
Konkret geht es garnicht mal so sehr um einen IP-Konflikt (damit ist eigentlich auch etwas anderes gemeint - 2 Hosts im gleichen Netzsegment mit der gleichen IP), sondern darum, dass Dein Netz sich nicht mit einem anderen auf die Füsse tritt. Eine Netz - z.B. 192.168.178.0/24 - sollte nur "einmal" vorhanden sein. Das gilt jetzt grundsätzlich erstmal nur für für Dich und Deine internen Netze, ABER... vielleicht kommst Du ja mal in die Verlegenheit ein Site2Site-VPN aufzubauen, dann hast Du direkt ein Problem, wenn das gegenüberliegende Netz einem Deiner lokalen entspricht (vergleich das einfach mit 2 Häusern auf einer Strasse, welche beide die gleiche Hausnummer haben). Alternativ "kann" (muss nicht, die Metrik sollte es schon regeln) es auch Probleme geben, wenn Du von einem Fremdstandort eine VPN-Einwahl zu Dir vornimmst und dort ein ähnliches Netz wie bei Dir Zuhause vorhanden ist (z.B. Fritzbox-Standart). Dann hättest Du "lokal" 192.168.178.0/24, als auch durch den VPN-Tunnel 192.168.178.0/24. Ist also mitunter dann nicht so glücklich...
Könnte ich bei den VLANs in der Theorie auch ein Subnetz verwenden, wenn ich penibel darauf achte, dass IPs keinesfalls doppelt vorkommen beim Routen zwischen den Netzen.
Mir ist klar, dass das überhaupt keinen Sinn macht
Dann ist ja gut, dass wir darüber gesprochen haben ;)

Ein VLAN ist i.d.R. ein eigenes Subnetz, da gibt es eher kein "könnte", sondern es ist eher ein "ist" 🙃 Tu Dir selbst einen Gefallen und vermisch mal nicht die Begriffe "Subnetz" und "IP", das ist, als würdest Du "Raum" und "Stuhl" vermischen. Ein Stuhl befindet in einem Raum. Ein Raum wird sich nicht in einem Stuhl befinden. Gleiches gilt für das Subnetz und eine IP-Adresse. Eine IP hat ein "Host" Netzteilnehmer. Der Netzteilnehmer befindet sich innerhalb eines Subnetzes (oder mehreren, je nach Schnittstellen).

Mir ist klar, dass das überhaupt keinen Sinn macht, aber interessieren würde es mich, ob es generell funktionieren würde?
Nein, das vergiss mal ganz schnell wieder... Du kannst Netze aber vergrössern (verdoppeln), oder verkleinern (halbieren). In Deinem Szenario mit 4 Netzen, könntest Du 4 Netze á 64 Adressen erstellen

192.168.1.0/24 = 1 Netz á 256 Adressen
192.168.1.0/25 + 192.168.1.128/25 = 2 Netze á 128 Adressen
192.168.1.0/26 + 192.168.1.64/26 + 192.168.1.128/26 + 192.168.1.192/26 = 4 Netze á 64 Adressen

Dabei sei zu beachten, dass ein paar Adressen direkt raus sind:

1) Netz-ID (0/64/128/192, bei einem /24 ist es halt die "0")
2) Router/Gateway (meist die erste - oder letzte - IP im Netz, 1/65/129/193, bei einem /24 ist es oft die "1")
3) Broadcast (die letzte Adresse im Netz, 63,127,191,255, bei einem /24 eben die "255")

Im Falle der pfSense gäbe es also insgesamt 4 einzelne Netze (je /26), wobei die erste nutzbare IP im jeweiligen Netzsegment immer die pfSense wäre, halt die 1,65,129 und 193. Pro Netz 64-Adressen, abzüglich 3 Adressen (Netz-ID, Broadcast und Gatewy (pfSense)) bleiben pro Netz noch 61 Adressen zur "freien Verfügung".

EDIT: Falls es Dich interessiert, passende Stichworte dazu wären: Subnetting, Supernetting, VLSM
 
Zuletzt bearbeitet:
Moinsen,
um kurz endlich die Frage von @blurrrr an mich zu beantworten:
als ich die pfsense installiert habe im Heimnetz, war es für mein Seelenfrieden ein Bedürfnis, dass die pfsense NAT macht. Warum? Weil ich damals noch wenig(er) Ahnung von Firewalls, Regeln, VLANs und dem Rest hatte, konnte ich mich im Zweifelsfall immer auf NAT "verlassen", ähnlich wie ich es ja von der Fritzbox kannte. Darauf habe ich dann auch die VPN Konfiguration angelegt. Das Thema, NAT irgendwann mal abzuschalten auf der pfsense kommt mir auch immer wieder mal in den Sinn, meist steht dann aber was anderes an, und:
Ich selber habe mit doppelt NAT bislang kein Problem. Solange ein, zwei Dinge bedacht werden, läuft das.
;)
Also gilt:
if it's not broken, don't fix it...mal abgesehen davon, dass IPv4 insgesamt "broken" ist. Aber das wird auch ohne mein DoppelNAT nicht besser. 🤪
 
Das Thema, NAT irgendwann mal abzuschalten auf der pfsense kommt mir auch immer wieder mal in den Sinn, meist steht dann aber was anderes an
Mhm... dauert... lass mich kurz überlegen... huch... in der "Denk-Phase" wäre es schon erledigt gewesen... aber klar, irgendwelche Ausreden finden sich ja immer 🤪:devilish:😁

Nochmal als kleine Erinnerung:
- Netze hinter der pfSense als Route auf der Fritzbox anlegen
- NAT auf der pfSense abschalten
- fertig
... so, jetzt sag ich dazu auch nix mehr, versprochen! 😇
 
"Glück" gibt es da "nicht" 😁 Funktioniert hat das ganze bisher aus folgendem Grund:

192.168.1.100 -> NAT (Umwandlung von 192.168.1.100 zu 192.168.178.3) -> Fritzbox-Netz

Pakete innerhalb eines Netzsegments brauchen keinen Router, sondern können "direkt" miteinander sprechen. Da in diesem Fall der pfSense-LAN-Client im Fritzbox-Netz mit der WAN-IP der pfSense erscheint, können die Fritzbox-Netz-Teilnehmer die Antwort "direkt" an die WAN-IP der pfSense schicken, welche die Antwort wieder dem pfSense-LAN-Client zuordnet (mittels NAT-Tabelle).
Sorry, aber jetzt verstehe ich es gar nicht mehr.
Das ist doch eigentlich immer der Fall, weil die Sense doch beim doppelten NAT immer mit der IP 192.168.178.3 mit der Fritzbox kommuniziert oder?
Egal ob intern in der Sense ein 192.168.1.100, 192.168.10.100, 192.168.20.100 Subnetz oder was auch immer durch die NAT Umwandlung über die 192.168.178.3 mit der Fritzbox kommuniziert.
 
Moinsen,
Ich behaupte mal ketzerisch: im Alltag wirst du vermutlich keinen Unterschied merken...
Ohne extra NAT "schonst" du die pfsense und manche Anwendungen zicken wohl wirklich mit doppelt NAT rum...

Wenn die PWL auf der fritzbox richtig gesetzt ist, du die pfsense Firewallregel am WAN interface korrekt einrichtest, dann ist IMHO für den Hausgebrauch kein Unterschied zu bemerken.

Und nochmal kurz @blurrrr: bei meiner langsamen tipperei dauert das einrichten der routen...das geht nicht mal eben so. Gibt ja eiligere und wichtigere Dinge...:LOL:
 
Das ist doch eigentlich immer der Fall, weil die Sense doch beim doppelten NAT immer mit der IP 192.168.178.3 mit der Fritzbox kommuniziert oder?
Das ist nicht der Fall, wenn die pfSense kein NAT macht, dann redet der Client hinter der pfSense mit "seiner" IP mit der Fritzbox. Beim doppelten NAT wird die pfSense-Client-IP beim Transport über die pfSense in die WAN-IP der pfSense umgeschrieben. Ist eben die Frage, ob einfach nur die 192.168.178.3 beim Login auf der Fritzbox im Fritzbox-Log auftaucht, oder eben die 192.168.1.100.
 
Das ist nicht der Fall, wenn die pfSense kein NAT macht, dann redet der Client hinter der pfSense mit "seiner" IP mit der Fritzbox.
Also kann ich mir das dann so merken?
Wenn die Sense NAT macht, dann ist eine statische Route zwischen Sense und Fritzbox nicht nötig, aber schadet in keinem Fall.
Wenn die Sense kein NAT macht, dann ist eine statische Route zwischen Sense und Fritzbox nötig.
 
Korrekt, mit NAT keine statische Routen auf der Fritzbox, ohne NAT müssen sie vorhanden sein :)
Danke für die Bestätigung.
Mir haben übrigens auch deine Tipps zum einlesen in die Begriffe viel gebracht.
Ich will nicht sagen, dass ich jetzt komplett durchgestiegen bin, aber so ein wenig lichtet sich der Nebel und es kommt Licht durch :D
 

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
4.380
Beiträge
45.239
Mitglieder
3.982
Neuestes Mitglied
ThomasW
Zurück
Oben