OPNsense Forum
International Forums => German - Deutsch => Topic started by: Hellgirl on May 04, 2021, 11:13:17 am
-
Hi Community :-)
Ich brauche leider etwas Hilfe.
Folgender Aufbau:
OPNsense am WAN Port: Vigor 165 im Bridged Mode. Internet und DNS klappt auf der OPNsense.
Am LAN Port hängt ein Layer 3 Cisco Switch mit mehreren VLAN´s dahinter.
Das VLAN Routing soll nur der Cisco Switch übernehmen. Die OPNsense soll sich ausschließlich um Internetverkehr kümmern.
IP OPNsense: 10.10.2.2
IP Switchport: 10.10.2.1
VLAN Routing macht der Layer 3 Switch selbst. Er hat also aus allen VLAN´s eine IP x.x.x.1.
Default Route am Switch 0.0.0.0/0 zur OPNsense 10.10.2.2.
An der OPNsense habe ich ein Gateway für ein Transfernetz zum Switch erstellt mit 10.10.2.1.
Darauf dann eine statische Route 10.10.0.0/16 auf 10.10.2.1er Gateway, damit er alle 10.10.x.x Netze auf den Switch sucht.
Das inter VLAN Routing klappt problemlos. Ich kann alles pingen.
Als allow Rule auf dem LAN Interface habe ich dann nicht nur das LAN Net zugelassen sondern 10.10.0.0/16 ANY.
Stecke ich mit diesem Setup das Netzwerkkabel direkt an den LAN Port der OPNsense und stelle den Netzwerkadapter auf z.B. 10.10.2.55, Gateway 10.10.2.2 und DNS 10.10.2.2 klappt das Internet auf dem Client sofort inklusive DNS Auflösung.
Stecke ich das ganze wieder an meinem Switch an und gehe mit z.B. VLAN 10 mit IP 10.10.10.15 ins Internet (DNS IP 10.10.2.2, Gateway Switch VLAN 10 IP 10.10.10.1), bekomme ich selbst per IP also ohne DNS keine Antwort. Ich kann aber weiterhin in alle VLAN´s pingen und ich erhalte auch von der OPNsense 10.10.2.2 eine Antwort.
Ich bin mit meinem Latein am Ende - vielleicht kann mich wer in die richtige Richtung stubsen? ;D
EDIT: Das ganze Setup ist so in der Form schon mit pfSense gelaufen. An OPNsense beisse ich mir aber scheinbar die Zähne aus :D
Das Tracert für z.B. die IP 1.1.1.1 vom Client 10.10.10.15 geht über seinen VLAN Gateway 10.10.10.1 zum Default Gateway 10.10.2.2 welcher ja die OPNsense ist und dann ist Feierabend :-( Von der OPNsense zur IP 10.10.10.15 kann ich problemlos pingen.
-
Ah, wahrscheinlich das Übliche ;). Outbound-NAT-Regeln fehlen. Default-Einstellung ist 'Automatic outbound NAT', dabei werden nur für die Subnetze der lokalen Interfaces Outbound-NAT-Regeln erstellt (hier wohl 10.10.2.0/24). Von 10.10.0.0/16 weiß das NAT nichts. Du musst daher umstellen auf hybrid oder manuell und selbst Regeln anlegen.
Grüße
Maurice
-
Oh vielen vielen Dank Maurice ;D
Du hast mir wirklich sehr geholfen. Ich habe mir daran 3 Tage die Zähne ausgebissen ::)
Genau das war das Problem!
Vermutet habe ich sowas schon. Wenn ich aus meinem VLAN 10 nen Ping nach 1.1.1.1 machte, sah man im Firewall Log, dass die Anfrage über das WAN tatsächlich raus ging. Aber zurück konnte er dann natürlich nicht, aufgrund der fehlenden NAT Rule.
Komisch finde ich nur, dass es in der pfSense auch auf "Automatic outbound NAT" gestellt war, dort in den Automatiklisten aber das 10.10.0.0/16 Netz auftaucht (siehe Screenshot). Irgendeine "Automatik" hat das Netz dort wohl eingetragen, die es so in der Form in der OPNsense nicht gibt.
Im Unbound DNS muss in den Zugriffslisten bei diesem Setup auch noch das 10.10.0.0/16 er Netz(e) eingetragen werden, damit die Anfragen nicht mit "refused" abgewiesen werden, da ja hinter dem LAN nicht nur ein Netz wartet. Hier lieferte Wireshark die Antwort, warum die DNS Auflösung fehlschlug.
Magst du dir bitte meinen Screenshot von der NAT outbound Rule ansehen? Die sollte so passen, ja?
Vielen Dank nochmal für deine Hilfe - die war echt Gold wert ;-)
-
Screenshot sieht gut aus. Und gut erkannt mit der Unbound-Zugriffsliste, auch das ist korrekt.
Was genau pfSense da für eine Automatik hat weiß ich nicht. Evtl. werden automatisch Regeln für statisch geroutete Zielnetze erstellt? Für meinen Geschmack etwas zu viel Automagic. Verständlich, dass man bei einem Umstieg dann natürlich lange sucht. :)
Grüße
Maurice
-
Das könnte sein, dass bei statischen Routen diese Regeln automatisch erstellt werden. Glaube ich aber in dem Fall eigentlich nicht, da ansonsten wohl eine separat zusätzliche Regel erstellt worden wäre.
Ich glaube ich weiß aber jetzt woher er das zieht: Ich habe die Allow All Standard Regel von "LAN Net" als Source nicht gelöscht und neu gesetzt, sondern die Standard Allow All Regel umgebogen auf mein Netz 10.10.0.0/16 und ich denke mal, daher wird er diese Info für NAT erhalten haben.
Da könnte ja z.B. auch einer nur einen anderen Adapter auswählen und es würde nicht korrekt genattet werden, wenn der User nicht an die NAT Regeln denkt.
Daher gehe ich stark davon aus, dass die Standard Allow Rule nicht nur einmal initial geprüft wird, sondern das diese sozusagen permanent überwacht wird :-)
Naja wie auch immer - vielen Dank nochmal für deine Hilfe :-)
Ich muss schon sagen, an vielen Ecken gefällt mir OPNsense schon deutlich besser als pfSense. Irgendwie wirkt pfSense dagegen oft etwas "antiquiert" :D
-
Maurice kannst du mir vielleicht nochmal auf die Sprünge helfen? ;D
Ich habe noch ein Problem mit dem ich nicht weiter komme.
Ich betreibe in meinem LAN einen Nextcloud Server. Diesen will ich per Domain von außen erreichen. Das klappt. Ich erreiche ihn aber nicht aus dem LAN. Hier ist das Stichwort ja NAT Reflection soweit ich weiß.
NAT Reflection klappt aber hier nur, wenn der LAN Client im selben Subnet liegt, wie die OPNsense. Komme ich aus einem anderen LAN Subnet, bekomme ich einen Timeout auf meiner Domain. Die Domain löst korrekt auf die WAN Adresse auf.
Ich denke hier ist das Problem wieder Routing/Outbound Rules oder wo muss ich da ansetzen?
OPNsense IP im VLAN2: 10.10.2.2
Nextcloud IP im VLAN3: 10.10.3.8
Client PC im VLAN10: 10.10.10.15 // NAT Reflection geht nicht und per Domain kommt keine Antwort.
OPNsense IP im VLAN2: 10.10.2.2
Nextcloud IP im VLAN3: 10.10.3.8
Client PC im VLAN10: 10.10.2.100 // NAT Reflection arbeitet korrekt und ich komme auch per Domain auf die
Nextcloud.
Vielen Dank schon mal für deine Antwort :-)
-
Mit NAT Reflection unter OPNsense habe ich leider keine Erfahrung. Das ist eigentlich nur eine Behelfslösung, falls es nicht z. B. mit IPv6 oder Split DNS umsetzbar ist.
Falls es NAT Reflection sein muss vielleicht besser ein neues Thema aufmachen.
Grüße
Maurice
-
Oh das wusste ich nicht, dass es nur eine Behelfslösung ist. Ich Frage mal parallel wegen NAT Reflection nach. Würde schon gerne wissen, was ich da falsch mache :-) Aber ich gehe mal schwer davon aus, dass die NAT Reflection irgendwie ein falsches Subnet zuweißt.
Wenn es eine bessere Methode gibt, implementiere ich auch gerne diese :-)
Mein Netzwerk ist leider noch nicht komplett auf IPV6 umgestellt, von daher fällt das raus.
Wie sähe die Split DNS Lösung aus?
EDIT: Ich glaube ich hab es schon richtig - siehe Screenshot?! :-) Wo liegen hier im Vergleich zur NAT Reflection die Vorteile?