8
Public IP Netz auf OPNsense richtig nutzen
Hallo zusammen,
auch wenn ich schon länger hier viele Themen verfolge, kommt nun mein erster eigener Beitrag. Ich hoffe, dass ich zukünftig auch mit meiner Expertise unterstützen kann.
Zu meinem Thema:
Ich plane grade eine Netzwerkstruktur mit, im Kern, einer OPNsense Firewall (virtualisiert), welche sowohl die Rollen von Firewall, Router und VPN Site-to-Side Gateway übernehmen soll.
Grober Netzwerkplan:
Dies ist lediglich eine grobe Übersicht, da es noch mehr Switche (teilweise virtualisiert) und VLAN Netze geben wird. Zur Veranschaulichung meiner Fragen sollte dies aber reichen.
Der MikroTik macht als Hardware mit GPON Modul die PPPoE Einwahl auf den Telekom Anschluss mit fester IP Adresse.
Über VLAN 2000 kann nun die virtualisierte OPNsense Firewall auf 10.200.0.1 als hinterlegtes Gateway zugreifen um sich zum Internet zu verbinden.
Diese Verbindung soll aber NUR für einen Zweck genutzt werden und zwar um eine geroutete VPN Verbindung aufzubauen.
Das Interface bekommt auf dem VPN Tunnelnetz auf dem Interface die IP 4.5.6.2/30 zugewiesen mit 4.5.6.1/30 als Gegenstelle.
Durch das Tunnelnetz wird nun auf die IP 4.5.6.2 als Routingziel das public IP Netz 1.2.4.0/24 geroutet.
Nun lege ich ein VLAN Interface 2002 an mit der IP 1.2.4.1/24 und weitere virtuelle IP Adressen mit Zuweisung zu diesem Interface.
Ziel ist nun den gesammten Internettraffic nach und von außen auf public IPs dieses Netzes durch den VPN zu schicken. Ich lege hier zu eine Out-NAT Regel an, welche die Quell IP auf 1.2.4.200 (Virtuelle IP) festlegt. Des weiteren wähle ich in den Firewallregeln dazu ein zweites default Gateway, welches auf 4.5.6.1 zeigt.
Des weiteren lege ich Nat + Firewallregeln an, um z.B. 1.2.4.10 (Virtuelle IP) intern an einen Server weiterzugeben.
Ich nutze also das komplette IP Netz "intern" an der OPNsense Firewall für NAT <-> VPN Tunnel.
Das habe ich in einer virtualisierten Umgebung auch schon getestet und es funktioniert auch soweit, jedoch habe ich Fragen bezüglich der Richtigkeit und Optimierung:
1. Ich gebe im MikroTik das komplette 10.0.0.0/8 als Routingziel die 10.200.0.2 an, um ausgehendes NAT bis zum MikroTik zu vermeiden und die Rückroute entsprechend zu sichern. Grund hier ist der weitere Zugriff auf das Interface vom MicroTik und unnötiges NAT vermeiden. Es wird das am Interface anligende Netz höher priorisiert (10.200.0.1/30) als die Route 10.0.0.0/8 richtig?
2. Nutze ich das Public IP Netz geroutet durch die VPN mit einem Interface + Virtuellen IPs so richtig? Oder gibt es eine bessere Lösung?
3. Da das VLAN 2002 Netz mit dem Public IP Netz ja nur "intern" genutzt wird, findet dort überhaupt Layer 2 Traffic statt? Könnte ich somit auch die Gateway und Broadcast Adresse .1 und .255 als Adresse beim ein- oder ausgehenden NAT Nutzen? Oder Wird es wie Layer 2 genutzt und von NAT -> Virtuellen IP -> VLAN 2002 Interface 1.2.4.1/24 -> VPN Tunnel ?
4. Ich muss aber generell das VLAN Interface mit 1.2.4.1/24 anlegen damit OPNsense dieses Netz überhaupt in seiner Routingtabelle hat und weiß was es mit den ankommenden Paketen auf dem VPN Interface anfangen soll richtig ?
5. Insgesammt habe ich nur 2 Gateways 1x Telekom vor Ort und 1x VPN Tunnel richtig? Alles andere mit den public IPs mache ich komplett über NAT?
6. Wie kann ich einstellen, dass NUR der VPN Aufbau über das 1. Gateway (Telekom vor Ort) geht und alles andere (inkl. der OPNsense selbst (Firmware akt., DNS, weitere VPN Tunnel)) über das 2. Gateway des VPN Tunnels. Den Netzwerkverkehr der Netze kann ich über die Firewallregeln ja ein Routing "aufzwingen" jedoch was mache ich mit der Firewall selbst ?
Oder reicht es hier diese erste VPN auf das Interface mit VLAN 2000 der Telekom Leitung zu binden ?
7. Wenn ich Datenverkehr aufs WAN zulassen möchte ist es die richtige Methode in OPNsense ein Alias aller privaten IP Blöcke zu erstellen und diesen als Ziel in einer Firewallregel zu negieren? :o
Ich danke für alle die sich in diese, doch nicht ganz alltägliche, Struktur reindenken.
Leider sieht man irgendwann vor lauter Bäumen den Wald nicht mehr. Die Funktionen sind nach ersten Tests schon soweit da und OK aber ich möchte es ja auch auf Zukunft stabil und konform aufbauen, deshalb die Verständnissfragen.
Ich hoffe ich habe alle relevanten Daten angegeben, ansonsten bitte noch mal genauer nachfragen.
Vielen Dank euch,
Thomas
auch wenn ich schon länger hier viele Themen verfolge, kommt nun mein erster eigener Beitrag. Ich hoffe, dass ich zukünftig auch mit meiner Expertise unterstützen kann.
Zu meinem Thema:
Ich plane grade eine Netzwerkstruktur mit, im Kern, einer OPNsense Firewall (virtualisiert), welche sowohl die Rollen von Firewall, Router und VPN Site-to-Side Gateway übernehmen soll.
Grober Netzwerkplan:
Dies ist lediglich eine grobe Übersicht, da es noch mehr Switche (teilweise virtualisiert) und VLAN Netze geben wird. Zur Veranschaulichung meiner Fragen sollte dies aber reichen.
Der MikroTik macht als Hardware mit GPON Modul die PPPoE Einwahl auf den Telekom Anschluss mit fester IP Adresse.
Über VLAN 2000 kann nun die virtualisierte OPNsense Firewall auf 10.200.0.1 als hinterlegtes Gateway zugreifen um sich zum Internet zu verbinden.
Diese Verbindung soll aber NUR für einen Zweck genutzt werden und zwar um eine geroutete VPN Verbindung aufzubauen.
Das Interface bekommt auf dem VPN Tunnelnetz auf dem Interface die IP 4.5.6.2/30 zugewiesen mit 4.5.6.1/30 als Gegenstelle.
Durch das Tunnelnetz wird nun auf die IP 4.5.6.2 als Routingziel das public IP Netz 1.2.4.0/24 geroutet.
Nun lege ich ein VLAN Interface 2002 an mit der IP 1.2.4.1/24 und weitere virtuelle IP Adressen mit Zuweisung zu diesem Interface.
Ziel ist nun den gesammten Internettraffic nach und von außen auf public IPs dieses Netzes durch den VPN zu schicken. Ich lege hier zu eine Out-NAT Regel an, welche die Quell IP auf 1.2.4.200 (Virtuelle IP) festlegt. Des weiteren wähle ich in den Firewallregeln dazu ein zweites default Gateway, welches auf 4.5.6.1 zeigt.
Des weiteren lege ich Nat + Firewallregeln an, um z.B. 1.2.4.10 (Virtuelle IP) intern an einen Server weiterzugeben.
Ich nutze also das komplette IP Netz "intern" an der OPNsense Firewall für NAT <-> VPN Tunnel.
Das habe ich in einer virtualisierten Umgebung auch schon getestet und es funktioniert auch soweit, jedoch habe ich Fragen bezüglich der Richtigkeit und Optimierung:
1. Ich gebe im MikroTik das komplette 10.0.0.0/8 als Routingziel die 10.200.0.2 an, um ausgehendes NAT bis zum MikroTik zu vermeiden und die Rückroute entsprechend zu sichern. Grund hier ist der weitere Zugriff auf das Interface vom MicroTik und unnötiges NAT vermeiden. Es wird das am Interface anligende Netz höher priorisiert (10.200.0.1/30) als die Route 10.0.0.0/8 richtig?
2. Nutze ich das Public IP Netz geroutet durch die VPN mit einem Interface + Virtuellen IPs so richtig? Oder gibt es eine bessere Lösung?
3. Da das VLAN 2002 Netz mit dem Public IP Netz ja nur "intern" genutzt wird, findet dort überhaupt Layer 2 Traffic statt? Könnte ich somit auch die Gateway und Broadcast Adresse .1 und .255 als Adresse beim ein- oder ausgehenden NAT Nutzen? Oder Wird es wie Layer 2 genutzt und von NAT -> Virtuellen IP -> VLAN 2002 Interface 1.2.4.1/24 -> VPN Tunnel ?
4. Ich muss aber generell das VLAN Interface mit 1.2.4.1/24 anlegen damit OPNsense dieses Netz überhaupt in seiner Routingtabelle hat und weiß was es mit den ankommenden Paketen auf dem VPN Interface anfangen soll richtig ?
5. Insgesammt habe ich nur 2 Gateways 1x Telekom vor Ort und 1x VPN Tunnel richtig? Alles andere mit den public IPs mache ich komplett über NAT?
6. Wie kann ich einstellen, dass NUR der VPN Aufbau über das 1. Gateway (Telekom vor Ort) geht und alles andere (inkl. der OPNsense selbst (Firmware akt., DNS, weitere VPN Tunnel)) über das 2. Gateway des VPN Tunnels. Den Netzwerkverkehr der Netze kann ich über die Firewallregeln ja ein Routing "aufzwingen" jedoch was mache ich mit der Firewall selbst ?
Oder reicht es hier diese erste VPN auf das Interface mit VLAN 2000 der Telekom Leitung zu binden ?
7. Wenn ich Datenverkehr aufs WAN zulassen möchte ist es die richtige Methode in OPNsense ein Alias aller privaten IP Blöcke zu erstellen und diesen als Ziel in einer Firewallregel zu negieren? :o
Ich danke für alle die sich in diese, doch nicht ganz alltägliche, Struktur reindenken.
Leider sieht man irgendwann vor lauter Bäumen den Wald nicht mehr. Die Funktionen sind nach ersten Tests schon soweit da und OK aber ich möchte es ja auch auf Zukunft stabil und konform aufbauen, deshalb die Verständnissfragen.
Ich hoffe ich habe alle relevanten Daten angegeben, ansonsten bitte noch mal genauer nachfragen.
Vielen Dank euch,
Thomas
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 665005
Url: https://administrator.de/contentid/665005
Printed on: April 16, 2024 at 04:04 o'clock
8 Comments
Latest comment
1.)
Richtig.
2.)
Nein, denn es gibt ein paar Unklarheiten im Konzept:
Die Antwort ist abhängig vom in Punkt 2. angesprochenen Problem. In einer gerouteten VPN Umgebung geht das so nicht. Du kannst ein VLAN nicht über Router Hops legen. Logisch, denn VLAN ist eine reine Layer 2 Technik. VPN (fast) immer geroutet. Wenn du über geroutete Verbindungen Bridgen willst brauchst du andere Technologien.
4.)
Nein, eine statische oder dynamische Route würde dafür ja völlig reichen die der OPNsense sagt: Das 1.2.4.0er IP Netz erreichst du über das Gateway 4.5.6.1 im VPN Interface.
5.)
Richtig.
6.)
Das macht man ganz einfach über Policy Based Routing. Du klassifizierst den VPN Traffic über eine Regel oder ACL und weist dem dann fest eins der beiden WAN Interfaces zu.
7.)
Kann man so machen oder du nutzt dort auch PBR. Letzteres ist kosmetisch etwas besser.
Richtig.
2.)
Nein, denn es gibt ein paar Unklarheiten im Konzept:
- Du schreibst "Durch das Tunnelnetz wird nun auf die IP 4.5.6.2 als Routingziel das public IP Netz 1.2.4.0/24 geroutet." was aber routingtechnsich falsch ist, denn man versteht es so das das öffentliche 1.2.4.0er IP Netz am anderen Ende des VPN Tunnels ist. Das Gateway dahin ist also dann die remote 4.5.6.1 und nicht die .2 !
- Damit fällt dann auch das NAT an der lokalen OPNsense flach, denn du kannst dort nicht auf das 1.2.4.0er IP Netz NATen, denn sonst hättest du doppelte IP Adressen. NAT geht wen du routest, nur am anderen Ende des Tunnel. Jedenfalls wenn du auf IP Adressen aus dem 1.2.4.0er IP Netz NATest. Ausnahe wäre du würdest das 1.2.4.0er IP Netz über den VPN Tunnel bridgen so das es direkt an deiner OPBsense anliegt aber davon ist ja nicht die Rede. Abgesehen davon ist Bridging immer schlecht aus Performance Sicht.
Die Antwort ist abhängig vom in Punkt 2. angesprochenen Problem. In einer gerouteten VPN Umgebung geht das so nicht. Du kannst ein VLAN nicht über Router Hops legen. Logisch, denn VLAN ist eine reine Layer 2 Technik. VPN (fast) immer geroutet. Wenn du über geroutete Verbindungen Bridgen willst brauchst du andere Technologien.
4.)
Nein, eine statische oder dynamische Route würde dafür ja völlig reichen die der OPNsense sagt: Das 1.2.4.0er IP Netz erreichst du über das Gateway 4.5.6.1 im VPN Interface.
5.)
Richtig.
6.)
Das macht man ganz einfach über Policy Based Routing. Du klassifizierst den VPN Traffic über eine Regel oder ACL und weist dem dann fest eins der beiden WAN Interfaces zu.
7.)
Kann man so machen oder du nutzt dort auch PBR. Letzteres ist kosmetisch etwas besser.
Hallo aqui,
erst mal danke ich dir für deine ausführlichen Antworten.
zu 1.
ich hatte auch noch die Idee die public IP über ein eigenes VLAN 2001 an das OPNsense Interface durchzureichen und den MikroTik die PPPoE Einwahl zu überlassen, und über VLAN 2000 weiterhin die Interne Verwaltung des MikroTik, jedoch kann man dies bei PPPoE wohl nicht auftrennen.
Ich hoffe nur das der auch laut Datenblatt die 1 Gbits WAN schafft mit ausgehendem NAT und routing.
zu 2.
Wenn ich deine Antwort lese glaube ich, dass ich es nicht gut genug erklärt habe und deshalb hier ein Missverständniss vorliegt. Du gehst davon aus, dass das IP Netz 1.2.4.0/24 über den VPN Tunnel erreichbar sein soll ? Das ist aber so nicht meine Absicht.
Ich bekomme am entfernten Standort von der RIPE ein größeres Netz zugewiesen und es wird nun das Teilnetz 1.2.4.0/24 durch den VPN meiner OPNsense als Router angegeben. Ich habe dies noch mal veranschaulicht:
1.2.0.0/16 --> zentraler Router -> VPN 4.5.6.1/30 ----------------> VPN 4.5.6.2/30 (meine OPNsense) -> 1.2.4.0/24
Internet/BGP --> RZ_woanders ----------------------> Internet ------> Telekom WAN -> meine OPNsense
Der zentrale Router im RZ_woanders hat den Routing-Tabellen Eintrag 1.2.4.0/24 -> 4.5.6.2
Und nun noch mal zu meiner Frage, da ich dieses Netz nur für ein und ausgehendes NAT an meiner OPNsense verwende, ist es so korrekt ein VLAN Interface anzulegen mit 1.2.4.1/24 und weitere virtuelle IPs ?
zu 3.
Durch Punkt 2 noch mal auch hier die Frage: mit einem Interface und virtuellen IPs könnte ich alle IPs Nutzen oder passiert auch Intern dort Layer 2 Traffic für die ein Gateway und Broadcast erforderlich ist?
zu 4.
Siehe Punkt 2. Das Netz liegt bei mir, nicht woanders und da ich es an meiner OPNsense auch fürs NAT verwenden will muss die Routing Tabelle es ja auch lokal bei mir anliegen sehen. Also keine statische Route woanders hin korrekt?
zu 6.
Soweit ich das gesehen habe kann ich das mit jeglichem Netzwerkverkehr von "außen" machen der an den Interfaces ankommt. Jedoch habe ich gesehen, dass die Firewall sich selbst immer erlaubt auch ohne Firewallregel überall hin zu kommen vom eigenen Interface. Eventuell eine Optionseinstellung ? Und der Tunnel wird ja auch von der Firewall aufgebaut. Kann ich das mit einer ACL in der Firewall "überschreiben" ?
zu 7.
okey über PBR wäre auch mein Favorit.
Also nur für mein Verständniss, wenn ich bei einer ACL ein Gateway mit angebe, MUSS der Traffic auch über dieses Gateway raus gehen, dass heißt lokal anliegende Netze (andere VLANs) kann ich bei angegebenem Gateway selbst dann nicht erreichen, wenn bei Ziel "*" steht?
Vielen Dank,
Thomas
erst mal danke ich dir für deine ausführlichen Antworten.
zu 1.
ich hatte auch noch die Idee die public IP über ein eigenes VLAN 2001 an das OPNsense Interface durchzureichen und den MikroTik die PPPoE Einwahl zu überlassen, und über VLAN 2000 weiterhin die Interne Verwaltung des MikroTik, jedoch kann man dies bei PPPoE wohl nicht auftrennen.
Ich hoffe nur das der auch laut Datenblatt die 1 Gbits WAN schafft mit ausgehendem NAT und routing.
zu 2.
Wenn ich deine Antwort lese glaube ich, dass ich es nicht gut genug erklärt habe und deshalb hier ein Missverständniss vorliegt. Du gehst davon aus, dass das IP Netz 1.2.4.0/24 über den VPN Tunnel erreichbar sein soll ? Das ist aber so nicht meine Absicht.
Ich bekomme am entfernten Standort von der RIPE ein größeres Netz zugewiesen und es wird nun das Teilnetz 1.2.4.0/24 durch den VPN meiner OPNsense als Router angegeben. Ich habe dies noch mal veranschaulicht:
1.2.0.0/16 --> zentraler Router -> VPN 4.5.6.1/30 ----------------> VPN 4.5.6.2/30 (meine OPNsense) -> 1.2.4.0/24
Internet/BGP --> RZ_woanders ----------------------> Internet ------> Telekom WAN -> meine OPNsense
Der zentrale Router im RZ_woanders hat den Routing-Tabellen Eintrag 1.2.4.0/24 -> 4.5.6.2
Und nun noch mal zu meiner Frage, da ich dieses Netz nur für ein und ausgehendes NAT an meiner OPNsense verwende, ist es so korrekt ein VLAN Interface anzulegen mit 1.2.4.1/24 und weitere virtuelle IPs ?
zu 3.
Durch Punkt 2 noch mal auch hier die Frage: mit einem Interface und virtuellen IPs könnte ich alle IPs Nutzen oder passiert auch Intern dort Layer 2 Traffic für die ein Gateway und Broadcast erforderlich ist?
zu 4.
Siehe Punkt 2. Das Netz liegt bei mir, nicht woanders und da ich es an meiner OPNsense auch fürs NAT verwenden will muss die Routing Tabelle es ja auch lokal bei mir anliegen sehen. Also keine statische Route woanders hin korrekt?
zu 6.
Soweit ich das gesehen habe kann ich das mit jeglichem Netzwerkverkehr von "außen" machen der an den Interfaces ankommt. Jedoch habe ich gesehen, dass die Firewall sich selbst immer erlaubt auch ohne Firewallregel überall hin zu kommen vom eigenen Interface. Eventuell eine Optionseinstellung ? Und der Tunnel wird ja auch von der Firewall aufgebaut. Kann ich das mit einer ACL in der Firewall "überschreiben" ?
zu 7.
okey über PBR wäre auch mein Favorit.
Also nur für mein Verständniss, wenn ich bei einer ACL ein Gateway mit angebe, MUSS der Traffic auch über dieses Gateway raus gehen, dass heißt lokal anliegende Netze (andere VLANs) kann ich bei angegebenem Gateway selbst dann nicht erreichen, wenn bei Ziel "*" steht?
Vielen Dank,
Thomas
ad 1.)
Sorry, aber jetzt wirds etwas wirr bzw. was du hier in 1. schreibst ist so technisch unmöglich wie du es schilderst. Entweder reichst du den PPPoE Traffic mit der public IP per VLAN durch an die OPNsense und die macht die PPPoE Einwahl oder der MT macht das PPPoE, hät die public IP und du kaskadierst die OPNsense dahinter per Ethernet.
Das Management des MT kannst du ja immer und mit beiden Modi ins interne LAN weiterleiten, denn das hängt ja schlicht und einfach nur davon ab in welches VLAN du die Management IP Adresse des MT hängst.
Hier machst du wohl noch ein paar Denkfehler sowohl was die PPPoE Einwahl als auch was das MT Management anbetrifft ?!
Letztlich wäre es sinnvoller die PPPoE Einwahl auf zentral auch auf die OPNsense zu ziehen, denn so hast du hier ja quasi beide Interfaces und kannst mit einfachen Profilen arbeiten was du wohin routest. Das vereinfacht das Routing erheblich als wenn das Internet Interface erst über einen zusätzlichen Routing Hop über den MT erreicht werden kann.
Technisch ist aber natürlich beides möglich.
ad 2.)
Du willst dann also quasi den "normalen" Internet Traffic über den MT (oder OPNsense PPPoE Inetrface) abfackeln aber alles was von deinen lokalen LANs in dein öffentliches 1.2.4.0/24er Subnetz geht soll direkt über den VPN Tunnel dahingehen. Ist das so richtig ?
Wenn ja braucht es dafür nicht einmal ein Policy based Routing und dafür ist es dann auch völlig egal ob du den PPPoE auf dem MT oder Firewall terminierst.
ad 3.)
Nein dann nur gerouteter Traffic
ad 4.)
Korrekt.
ad 6.)
Zudem ist es Routing technisch auch von einer Route abhängig was wo hinkommt. Routing und Regelwerk muss also passen damit das passiert.
ad 7.
Brauchst du ggf. gar nicht. Viele VPN Protokolle injizieren die remoten IP Netze automatisch in die jeweilige Routing Tabelle beim Tunnel Aufbau. Ggf. kann man also einfach mit statischen Routen arbeiten oder macht dynamisches Routing was dann noch den Vorteil eines automatischen Failovers hat.
Es gibt viele Wege nach Rom...
Sorry, aber jetzt wirds etwas wirr bzw. was du hier in 1. schreibst ist so technisch unmöglich wie du es schilderst. Entweder reichst du den PPPoE Traffic mit der public IP per VLAN durch an die OPNsense und die macht die PPPoE Einwahl oder der MT macht das PPPoE, hät die public IP und du kaskadierst die OPNsense dahinter per Ethernet.
Das Management des MT kannst du ja immer und mit beiden Modi ins interne LAN weiterleiten, denn das hängt ja schlicht und einfach nur davon ab in welches VLAN du die Management IP Adresse des MT hängst.
Hier machst du wohl noch ein paar Denkfehler sowohl was die PPPoE Einwahl als auch was das MT Management anbetrifft ?!
Letztlich wäre es sinnvoller die PPPoE Einwahl auf zentral auch auf die OPNsense zu ziehen, denn so hast du hier ja quasi beide Interfaces und kannst mit einfachen Profilen arbeiten was du wohin routest. Das vereinfacht das Routing erheblich als wenn das Internet Interface erst über einen zusätzlichen Routing Hop über den MT erreicht werden kann.
Technisch ist aber natürlich beides möglich.
ad 2.)
Du gehst davon aus, dass das IP Netz 1.2.4.0/24 über den VPN Tunnel erreichbar sein soll ?
Ja, so versteht man es zumindestens wenn man deine Ausführungen oben liest. Ggf. solltest du nochmal eine besser verständliche Skizze nachreichen hier die rein den Layer 3 erklärt.und es wird nun das Teilnetz 1.2.4.0/24 durch den VPN meiner OPNsense als Router angegeben.
Ahhsooo, ok macht die Sache umso einfacher... Du willst dann also quasi den "normalen" Internet Traffic über den MT (oder OPNsense PPPoE Inetrface) abfackeln aber alles was von deinen lokalen LANs in dein öffentliches 1.2.4.0/24er Subnetz geht soll direkt über den VPN Tunnel dahingehen. Ist das so richtig ?
Wenn ja braucht es dafür nicht einmal ein Policy based Routing und dafür ist es dann auch völlig egal ob du den PPPoE auf dem MT oder Firewall terminierst.
ad 3.)
Nein dann nur gerouteter Traffic
ad 4.)
Korrekt.
ad 6.)
dass die Firewall sich selbst immer erlaubt auch ohne Firewallregel überall hin zu kommen vom eigenen Interface.
Nein das ist Unsinn. Bei einer Firewall ist sämtlicher Traffic immer Firewall üblich geblockt. Du musst alles explizit erst zulassen. OK, einzige Ausnahme ist die Default Scheunentor Regel am lokalen LAN Interface die alle Firewalls immer mitbringen. Ansonsten wäre eine initiale Konfig ja nur über ein serielles Interface möglich und niemals über LAN und GUI.Zudem ist es Routing technisch auch von einer Route abhängig was wo hinkommt. Routing und Regelwerk muss also passen damit das passiert.
Und der Tunnel wird ja auch von der Firewall aufgebaut.
Nein, nicht zwingend und kann man so nicht sagen. Ein VPN Tunnel hat ja immer 2 Enden. Du musst immer bestimmen wer der Initiator (Aufbau) ist und wer der Responder (nimmt an) ist. Das ist bei allen gängigen VPN Protokollen so. Leider schreibst du ja nicht welches du planst zu verwenden ?!ad 7.
Brauchst du ggf. gar nicht. Viele VPN Protokolle injizieren die remoten IP Netze automatisch in die jeweilige Routing Tabelle beim Tunnel Aufbau. Ggf. kann man also einfach mit statischen Routen arbeiten oder macht dynamisches Routing was dann noch den Vorteil eines automatischen Failovers hat.
Es gibt viele Wege nach Rom...
Hallo aqui,
zu 1.
Das das etwas Wirr ist, war mir klar und sagte ja oben auch wird technisch so nicht umsetzbar sein. Das war eine theoretische "nice to have" Überlegung von meiner Seite :D
Bin ich bei der PPPoE Einwahl auf VLAN 7 festgelegt oder kann ich das belibig wählen?
Würde ich dann über ein zweites privates VLAN an den MT dran kommen ?
PPPoE durchreichen hieße hier GPON und VLAN bridgen ?
Letzlich wenn ich auch ein anderes VLAN als "7" wählen kann würde ich auch das PPPoE durchreichen bevorzugen.
zu 2.
Sry wegen der Verwirrung, ich hoffe ich konnte das Routing durch den VPN genauer mit der 2. Skizze verdeutlichen.
Mein Ziel ist es ALLES über das public IP 1.2.4.0/24 Netz, sowohl eingehend als auch ausgehenden Datenverkehr, zu routen. Dazu zählen natürlich alle LANs/DMZs (Alles was ein VLAN hat) PLUS die OPNsense selbst (Firmware update, DNS Abfrage, weitere VPN Tunnel.)
Die einzige offensichtliche Außnahme soll der Basis-VPN Tunnel sein, durch den dieses public Netz überhaupt erst geroutet wird. Logischerweise kann ich kein VPN durch den eigenen Tunnel aufbauen. :D Dieser muss also seinen Weg über das PPPoE der Telekom lokal finden.
Am liebsten wäre mir hier also gar kein GW für die Telekom-Leitung anzulegen, aber da komme ich wohl nicht drum herum, dass die Verbindung überhaupt aufgebaut werden kann.
zu 3.
ok das heißt alle IPs sind als Virtuelle IPs Nutzbar.
zu 6.
Ich gebe dir hier Recht für allen eingehenden Traffic auf allen Interfaces. Dieser wird per Default blockiert mit einziger Außnahme der Default Lan Regel zu Any und der AntiLockOut Regel, die man in der Config deaktivieren kann. Soweit klar. Jedoch der interne Traffic der von der Firewall selbst über ein Interface/Route raus geht ist davon nicht betroffen.
Zumindest verstehe ich so folgenden Auszug aus dem Firewall Log meines Testaufbaus bei einer Firmwareanfrage an OPNsense + DNS Anfrage an meinen lokalen DNS Server:
Und nach meinem Verständniss heißt das, dass die Firewall selbst sich default alles ausgehend erlaubt und einfach das erst beste GW für sein Zeug nimmt ? Genau das möchte ich auch einstellen könnnen. Die Regeln aus Netzen ist klar verständlich.
Beim VPN wäre die OPNsense grundsätzlich Initiator und die Gegenstelle Responder. Als Protokoll kommen nur zwei in Frage, wobei ich das selbst noch nicht weiß, da das auch von der Gegenstelle abhängt: openVPN oder IKEv2 aufgrund von Sicherheit und Performance. Wobei mein Favorit schon IKEv2 wäre.
Aber auch hier würde die Firewall ohne Firewallregel einfach aufbauen können. Kann ich diese selbst auch irgendwie beschränken ?
zu 7.
hier geht es eher weniger um den VPN Tunnel, sondern mehr um eine WAN Regel ohne private IP Netzwerk Negation als Ziel.
Die SonicWall zb arbeitet hier mit Zonen (wobei ich das auch nicht Ideal finde).
Deshalb grade meine Überlegung (ungetestet): Ich gebe in der Firewallregel ein GW mit an, kann dann aber lokale Netze nicht erreichen, da die durch die Routing Tabelle an Interfaces anliegen und somit nicht durch das GW erreichbar sein können.
Vielen Dank,
Thomas
zu 1.
Das das etwas Wirr ist, war mir klar und sagte ja oben auch wird technisch so nicht umsetzbar sein. Das war eine theoretische "nice to have" Überlegung von meiner Seite :D
Bin ich bei der PPPoE Einwahl auf VLAN 7 festgelegt oder kann ich das belibig wählen?
Würde ich dann über ein zweites privates VLAN an den MT dran kommen ?
PPPoE durchreichen hieße hier GPON und VLAN bridgen ?
Letzlich wenn ich auch ein anderes VLAN als "7" wählen kann würde ich auch das PPPoE durchreichen bevorzugen.
zu 2.
Sry wegen der Verwirrung, ich hoffe ich konnte das Routing durch den VPN genauer mit der 2. Skizze verdeutlichen.
Mein Ziel ist es ALLES über das public IP 1.2.4.0/24 Netz, sowohl eingehend als auch ausgehenden Datenverkehr, zu routen. Dazu zählen natürlich alle LANs/DMZs (Alles was ein VLAN hat) PLUS die OPNsense selbst (Firmware update, DNS Abfrage, weitere VPN Tunnel.)
Die einzige offensichtliche Außnahme soll der Basis-VPN Tunnel sein, durch den dieses public Netz überhaupt erst geroutet wird. Logischerweise kann ich kein VPN durch den eigenen Tunnel aufbauen. :D Dieser muss also seinen Weg über das PPPoE der Telekom lokal finden.
Am liebsten wäre mir hier also gar kein GW für die Telekom-Leitung anzulegen, aber da komme ich wohl nicht drum herum, dass die Verbindung überhaupt aufgebaut werden kann.
zu 3.
ok das heißt alle IPs sind als Virtuelle IPs Nutzbar.
zu 6.
Ich gebe dir hier Recht für allen eingehenden Traffic auf allen Interfaces. Dieser wird per Default blockiert mit einziger Außnahme der Default Lan Regel zu Any und der AntiLockOut Regel, die man in der Config deaktivieren kann. Soweit klar. Jedoch der interne Traffic der von der Firewall selbst über ein Interface/Route raus geht ist davon nicht betroffen.
Zumindest verstehe ich so folgenden Auszug aus dem Firewall Log meines Testaufbaus bei einer Firmwareanfrage an OPNsense + DNS Anfrage an meinen lokalen DNS Server:
Und nach meinem Verständniss heißt das, dass die Firewall selbst sich default alles ausgehend erlaubt und einfach das erst beste GW für sein Zeug nimmt ? Genau das möchte ich auch einstellen könnnen. Die Regeln aus Netzen ist klar verständlich.
Beim VPN wäre die OPNsense grundsätzlich Initiator und die Gegenstelle Responder. Als Protokoll kommen nur zwei in Frage, wobei ich das selbst noch nicht weiß, da das auch von der Gegenstelle abhängt: openVPN oder IKEv2 aufgrund von Sicherheit und Performance. Wobei mein Favorit schon IKEv2 wäre.
Aber auch hier würde die Firewall ohne Firewallregel einfach aufbauen können. Kann ich diese selbst auch irgendwie beschränken ?
zu 7.
hier geht es eher weniger um den VPN Tunnel, sondern mehr um eine WAN Regel ohne private IP Netzwerk Negation als Ziel.
Die SonicWall zb arbeitet hier mit Zonen (wobei ich das auch nicht Ideal finde).
Deshalb grade meine Überlegung (ungetestet): Ich gebe in der Firewallregel ein GW mit an, kann dann aber lokale Netze nicht erreichen, da die durch die Routing Tabelle an Interfaces anliegen und somit nicht durch das GW erreichbar sein können.
Vielen Dank,
Thomas
1.)
Welches VLAN Tagging du zum Provider machst bestimmt doch immer der Provider weil der das ja fest vorgibt. Die Frage ist also etwas sinnfrei, denn da hast du folglich keine Wahl.
Mit welcher VLAN ID du dann entweder die PPPoE Session oder das Internet intern in deinem Netz weitergibst kannst du selber bestimmen.
2.)
Jetzt wirds wieder wirr...
Langsam kann man dir wirklich nicht mehr folgen...
6.)
Aber was ist das schon ? Ein bischen NTP damit die FW ihre Uhr richtig stellen kann, DNS wenn sie selber Proxy ist und der VPN Management Traffic, viel mehr "internen" Traffic hat sie ja nicht.
7.)
Kann man so machen ist aber Routing technisch etwas unsauber.
Bin ich bei der PPPoE Einwahl auf VLAN 7 festgelegt oder kann ich das belibig wählen?
Vermutlich machst du hier wieder einen Denkfehler... Welches VLAN Tagging du zum Provider machst bestimmt doch immer der Provider weil der das ja fest vorgibt. Die Frage ist also etwas sinnfrei, denn da hast du folglich keine Wahl.
Mit welcher VLAN ID du dann entweder die PPPoE Session oder das Internet intern in deinem Netz weitergibst kannst du selber bestimmen.
2.)
Jetzt wirds wieder wirr...
Logischerweise kann ich kein VPN durch den eigenen Tunnel aufbauen.
Du meintest du kannst kein "VLAN" durch den Tunnel aufbauen, oder ?Langsam kann man dir wirklich nicht mehr folgen...
Am liebsten wäre mir hier also gar kein GW für die Telekom-Leitung anzulegen, aber da komme ich wohl nicht drum herum,
Nun ja, je nachdem wie man es sieht.- Internet via MT = Gateway zum Internet auf der OPNsense ist dann dein Koppel VLAN zum MT
- Internet auf der OPNsense = Gateway zum Internet ist dann die PPP Default Route via PPPoE Interface
6.)
der interne Traffic der von der Firewall selbst über ein Interface/Route raus geht ist davon nicht betroffen.
Da hast du Recht !Aber was ist das schon ? Ein bischen NTP damit die FW ihre Uhr richtig stellen kann, DNS wenn sie selber Proxy ist und der VPN Management Traffic, viel mehr "internen" Traffic hat sie ja nicht.
und einfach das erst beste GW für sein Zeug nimmt ?
Fragt sich wie du den Ausdruck "erst beste GW" für dich definierst ? Einfach willkürlich eins nimmt sie natürlich nicht, das weisst du als Profi ja auch selber. In der Routing Tabelle hat jede Route immer eine Metric und einzig allein die Metric entscheidet welche Route die Firewall für ihren ausgehenden Traffic nimmt. Das ist schon seit Jahrhunderten in Netzwerken so !!Wobei mein Favorit schon IKEv2 wäre.
Richtig, wäre sicher die erste Wahl wobei du auch noch Wireguard als Alternative hättest.Kann ich diese selbst auch irgendwie beschränken ?
Ja, das geht mit entsprechenden Routen und dem Regelwerk natürlich.7.)
Kann man so machen ist aber Routing technisch etwas unsauber.
Hallo aqui,
Heißt also ich ändere im MT einfach das VLAN Tag von 7 -> was ich gern möchte.
Das kann ich ja durch reines switching erledigen + 2. privates VLAN für MGMT.
Ich meine an dieser Stelle einfach, dass ich den 1. VPN Tunnel ja nicht durch sich selbst (GW des gerouteten Netzes durch den Tunnel) aufbauen kann weil er noch nicht exisitiert. Ich brauche hier das GW des Telekom-Anschlusses (PPPoE).
Sobald dieser steht nehme ich dann aber für alles andere das GW des Netzes was durch den Tunnel kommt.
Stimmt. Also besser über die FW-Regeln lösen für ein sauberes Routing.
Ich habe auch einen Weg gefunden und grade mal getestet. Diese Regel "default Allow from Firewall host" scheint ebenso unsichbar an unterster Stelle zu stehen wie die "Default Deny all incoming" Regel für eingenden Datenverkehr. Nun habe ich darüber mal eine Regel Ping von der Firewall to * verbieten und darüber eine Regel Ping zum DNS Server erlauben. Resultat sieht hier bei gut aus:
Sogar so gut, dass sogar das Gateway nicht mehr online ist, weil es nicht mehr geprüft werden kann
Heißt für mich ich kann auch die Firewall mit Regeln + PBR überschreiben
Über den Zeitraum hat sich das Konzept ja dann bewährt!
Leider kann ich die Metric direkt in der Weboberfläche nicht einsehen, ich sehe nur die Priorität (1-255) was ja einer Metric ähnlich kommt. Aber das "Upstream Gateway" Flag wird da auch noch eine Rolle spielen denke ich. Aus den beiden wird dann wohl die Metric gesetzt. Aber was passiert bei gleichen Einstellungen von zwei GW. Vielleicht kann man das über die Shell sehen.
Ja wobei da die Unterstützung noch nicht so groß ist. Wie gesagt das kann ich nicht allein entscheiden und muss Rücksicht auf meine Gegenstelle nehmen.
Findest du bei IKEv2 AES-265 SHA512 und PFS mit selbigen einen PSK ausreichend oder lieber Zertifikat? (PSK natürlich passend gewählt)
Wie meine Tests ja nun ergeben haben
Mir fallen bis jetzt nur die GW-Beschränkung und die Negation der lokalen Netze als Ziel ein.
Bin hier aber für jede Idee offen.
Vielen Dank,
Thomas
Zitat von @aqui:
1.)
Welches VLAN Tagging du zum Provider machst bestimmt doch immer der Provider weil der das ja fest vorgibt. Die Frage ist also etwas sinnfrei, denn da hast du folglich keine Wahl.
Mit welcher VLAN ID du dann entweder die PPPoE Session oder das Internet intern in deinem Netz weitergibst kannst du selber bestimmen.
Gut. Mehr wollte ich gar nicht wissen 1.)
Bin ich bei der PPPoE Einwahl auf VLAN 7 festgelegt oder kann ich das belibig wählen?
Vermutlich machst du hier wieder einen Denkfehler... Welches VLAN Tagging du zum Provider machst bestimmt doch immer der Provider weil der das ja fest vorgibt. Die Frage ist also etwas sinnfrei, denn da hast du folglich keine Wahl.
Mit welcher VLAN ID du dann entweder die PPPoE Session oder das Internet intern in deinem Netz weitergibst kannst du selber bestimmen.
Heißt also ich ändere im MT einfach das VLAN Tag von 7 -> was ich gern möchte.Das kann ich ja durch reines switching erledigen + 2. privates VLAN für MGMT.
2.)
Jetzt wirds wieder wirr...
Langsam kann man dir wirklich nicht mehr folgen...
Ups nein haha, das wäre natürlich totaler Quatsch (außer beim Layer 2 Tunnel). Tut mir leid für die Verwirrung.Jetzt wirds wieder wirr...
Logischerweise kann ich kein VPN durch den eigenen Tunnel aufbauen.
Du meintest du kannst kein "VLAN" durch den Tunnel aufbauen, oder ?Langsam kann man dir wirklich nicht mehr folgen...
Ich meine an dieser Stelle einfach, dass ich den 1. VPN Tunnel ja nicht durch sich selbst (GW des gerouteten Netzes durch den Tunnel) aufbauen kann weil er noch nicht exisitiert. Ich brauche hier das GW des Telekom-Anschlusses (PPPoE).
Sobald dieser steht nehme ich dann aber für alles andere das GW des Netzes was durch den Tunnel kommt.
Am liebsten wäre mir hier also gar kein GW für die Telekom-Leitung anzulegen, aber da komme ich wohl nicht drum herum,
Nun ja, je nachdem wie man es sieht.- Internet via MT = Gateway zum Internet auf der OPNsense ist dann dein Koppel VLAN zum MT
- Internet auf der OPNsense = Gateway zum Internet ist dann die PPP Default Route via PPPoE Interface
6.)
Aber was ist das schon ? Ein bischen NTP damit die FW ihre Uhr richtig stellen kann, DNS wenn sie selber Proxy ist und der VPN Management Traffic, viel mehr "internen" Traffic hat sie ja nicht.
Das stimmt schon, aber da bin ich (leider) immer ein bisschen Perfektionist, wo ich mir denke, dass muss doch gehen.der interne Traffic der von der Firewall selbst über ein Interface/Route raus geht ist davon nicht betroffen.
Da hast du Recht !Aber was ist das schon ? Ein bischen NTP damit die FW ihre Uhr richtig stellen kann, DNS wenn sie selber Proxy ist und der VPN Management Traffic, viel mehr "internen" Traffic hat sie ja nicht.
Ich habe auch einen Weg gefunden und grade mal getestet. Diese Regel "default Allow from Firewall host" scheint ebenso unsichbar an unterster Stelle zu stehen wie die "Default Deny all incoming" Regel für eingenden Datenverkehr. Nun habe ich darüber mal eine Regel Ping von der Firewall to * verbieten und darüber eine Regel Ping zum DNS Server erlauben. Resultat sieht hier bei gut aus:
Sogar so gut, dass sogar das Gateway nicht mehr online ist, weil es nicht mehr geprüft werden kann
Heißt für mich ich kann auch die Firewall mit Regeln + PBR überschreiben
und einfach das erst beste GW für sein Zeug nimmt ?
Fragt sich wie du den Ausdruck "erst beste GW" für dich definierst ? Einfach willkürlich eins nimmt sie natürlich nicht, das weisst du als Profi ja auch selber. In der Routing Tabelle hat jede Route immer eine Metric und einzig allein die Metric entscheidet welche Route die Firewall für ihren ausgehenden Traffic nimmt. Das ist schon seit Jahrhunderten in Netzwerken so !!Leider kann ich die Metric direkt in der Weboberfläche nicht einsehen, ich sehe nur die Priorität (1-255) was ja einer Metric ähnlich kommt. Aber das "Upstream Gateway" Flag wird da auch noch eine Rolle spielen denke ich. Aus den beiden wird dann wohl die Metric gesetzt. Aber was passiert bei gleichen Einstellungen von zwei GW. Vielleicht kann man das über die Shell sehen.
Wobei mein Favorit schon IKEv2 wäre.
Richtig, wäre sicher die erste Wahl wobei du auch noch Wireguard als Alternative hättest.Findest du bei IKEv2 AES-265 SHA512 und PFS mit selbigen einen PSK ausreichend oder lieber Zertifikat? (PSK natürlich passend gewählt)
Kann ich diese selbst auch irgendwie beschränken ?
Ja, das geht mit entsprechenden Routen und dem Regelwerk natürlich.7.)
Kann man so machen ist aber Routing technisch etwas unsauber.
Okey was würdest du hier vorschlagen ? Also als eine Allow all to WAN Regel ?Kann man so machen ist aber Routing technisch etwas unsauber.
Mir fallen bis jetzt nur die GW-Beschränkung und die Negation der lokalen Netze als Ziel ein.
Bin hier aber für jede Idee offen.
Vielen Dank,
Thomas
ich sehe nur die Priorität (1-255) was ja einer Metric ähnlich kommt.
Das ist in der Tat das gleiche.Aber was passiert bei gleichen Einstellungen von zwei GW.
Solltest du als Netzwerk Profi aber eigentlich wissen....Das kommt ganz darauf an wie die Routen gelernt wurden. Bei statischen Routen mit gleicher Metric wird ein Session basiertes Balancing gemacht ala eine da...die nächste da...die nächste wieder hier.
Dynamische Protokolle wie z.B. OSPF die damit umgehen können machen das ebenso (ECMP)
Ja wobei da die Unterstützung noch nicht so groß ist.
Da hast du Recht zumal es ja immer noch Beta deklariert ist. In Bezug auf Kompatibilität und Performance ist IKEv2 da derzeit die bessere Wahl, keine Frage.mit selbigen einen PSK ausreichend oder lieber Zertifikat?
Hängt von DEINER Sicherheits Policy ab die DU selber aufstellst. Oder fragst du in einem Auto Forum auch nach ob Airbag und ABS usw. ?
Hallo aqui,
sry für die späte Antwort, aber es ist/war massig viel Arbeit die letzten Wochen.
Das kommt ganz darauf an wie die Routen gelernt wurden. Bei statischen Routen mit gleicher metric wird ein Session basiertes Balancing gemacht ala eine da...die nächste da...die nächste wieder hier.
Dynamische Protokolle wie z.B. OSPF die damit umgehen können machen das ebenso (ECMP)
Ja das stimmt, jedoch versuche ich in der Praxis (außer bei gewolltem LoadBalancing durch Round Robin), dies zu vermeiden.
Hier war eher nach einer Empfehlung und Austausch von Erfahrung gefragt.
Um bei deinem Beispiel zu bleiben, kla ist man mit 12 Airbags aus allen Richtungen sicherer als mit 5, aber eventuell wird aus kostengründen doch meist nur 5 benutzt weil es 99% der Unfälle abdeckt. Neuste ESP ist nice, hat aber auch nicht jeder Neuwagen im höchsten Level. Oft ist da auch ESP Standard.
Die Frage war hier, was ist heut zu Tage noch "gängig" in der Praxis.
Notfalls die Technischen Richtlinien des BSI
sry für die späte Antwort, aber es ist/war massig viel Arbeit die letzten Wochen.
Zitat von @aqui:
Ja das denke ich auch wobei mich dann die Beschreibung des "Upstream Gateways" wundert als besondere Priorität?ich sehe nur die Priorität (1-255) was ja einer Metric ähnlich kommt.
Das ist in der Tat das gleiche.Aber was passiert bei gleichen Einstellungen von zwei GW.
Solltest du als Netzwerk Profi aber eigentlich wissen....Das kommt ganz darauf an wie die Routen gelernt wurden. Bei statischen Routen mit gleicher metric wird ein Session basiertes Balancing gemacht ala eine da...die nächste da...die nächste wieder hier.
Dynamische Protokolle wie z.B. OSPF die damit umgehen können machen das ebenso (ECMP)
mit selbigen einen PSK ausreichend oder lieber Zertifikat?
Hängt von DEINER Sicherheits Policy ab die DU selber aufstellst. Oder fragst du in einem Auto Forum auch nach ob Airbag und ABS usw. ? Um bei deinem Beispiel zu bleiben, kla ist man mit 12 Airbags aus allen Richtungen sicherer als mit 5, aber eventuell wird aus kostengründen doch meist nur 5 benutzt weil es 99% der Unfälle abdeckt. Neuste ESP ist nice, hat aber auch nicht jeder Neuwagen im höchsten Level. Oft ist da auch ESP Standard.
Die Frage war hier, was ist heut zu Tage noch "gängig" in der Praxis.
Notfalls die Technischen Richtlinien des BSI