Wenn Holger das ganze Firewall Gedöns weg lässt, muss er nur seine IP Adressen eintragen und das Standardgateway definieren.
Und das sollte das Interface mit der IP des Internetproviders sein.
Hallo Thomas,
Wenn Holger das ganze Firewall Gedöns weg lässt, muss er nur seine IP
Adressen eintragen und das Standardgateway definieren.
Und das sollte das Interface mit der IP des Internetproviders sein.
Danke für deine Hilfe.
Ich brauche aber das Firewalling: meine Server sollen schon hinter einer
Firewall sitzen 
LG
Holger
Hallo Holger,
dann hätte ich dich nicht richtig verstanden.
Ich bin davon ausgegangen, dass du das Firewalling erst danach auf der ipFire machst, und hier zunächst von einem öffentlichen Netz in ein anderes öffentliches Netz routen willst.
Ich weiß jetzt nicht wie du das eingerichtet hast. Standardmäßig geht die opnSense bei der Einrichtung davon aus, dass sie ein öffentliches Netz mit einem oder mehreren privaten Netzen per Masqerading verbindet und dementsprechend bereits die Regeln dafür anlegt.
Entweder man schaltet das Default Regelwerk für dieses Interface ab oder man vergibt diesem Interfaces eine (erwartete) private IP und legt ein zusätzliches Interface mit der IP des öffentlichen Netzes an.
Ggf. muss man dann noch die Standardregeln für das WAN Interface anpassen, damit der kein SourceNAT auf diesem Netze betreibt. Ich meine, dass dies auch zur Grundeinstellung der opnSense gehört, dies auf allen verbunden Netzen zu betreiben.
Das Ganze ist etwas hakelig, da die Distri für diesen Zweck so nicht gemacht wurde.
Viele Grüße
Thomas
Hallo Holger,
alles, was nach NAT aussieht (Outbound NAT, SNAT, …) ist auf jeden Fall falsch. Wo immer Du das abschalten kannst, solltest Du es tun.
Ich weiß aber auch nicht, wo Du dann Deine Regeln einträgst.
BestenGrüße
Jörg
Port Filterregeln kann man da ganz normal anlegen, wie gewohnt. Nur der NAT Kram muss weg. Und da wird’s doof, denn die opnSense macht das halt per Default. Das muss man dem Ding angewöhnen. Nur bei allem was per Voreinstellung gemacht ist, musst schauen, wie tief die Grundeinstellung greift.
Doof gesprochen ist es vermutlich simpler ein einfaches Linux (CentOS, Debian etc.) zu installieren, die Defaultroute anzulegen und die paar Regeln mit IPTables oder firewalld zu erstellen.
Liebe Grüße
Thomas
Hallo Holger,
habe es mir kurz angesehen - die ganz normalen Filterregeln sollten auch ohne NAT funktionieren.
Beste Grüße
Jörg
Hallo,
vielen Dank für eure Eingaben: jetzt muss das Projekt eh mal 3 Wochen
auf Eis:
ich hab Mathe Erstkorrektur hier und bekomme nächste WOche eine
Zweitkorrektur und dann am Ende noch eine Drittkorrektur: das ist alles
erstmal dringender 
Ich denke, dann stell ich die Frage einfach im OPNsense Forum: die
sollten den Einsatzzweck kennen.
LG
Holger
Hallo Holger,
das Thema ist schon ziemlich alt aber für mich gerade sehr aktuell, da ich genau das gleiche Problem habe und es noch nicht hinbekommen habe:
- OPNsense virtuell
- Transfernetz IP (auf neuem Interface angelegt (WAN2)) + Gateway angelegt. Komme darüber raus und rein, wenn ich die Rules entsprechend setze.
- Ein 29er Subnetz das laut ISP wohl auch auf WAN2 aufschlägt. Hab dafür ein weiteres Interface angelegt (HNET)
Hab schon alles möglich versucht:
Virtual IP’s (IP Aliase, Proxy ARP), 1:1 NAT usw.
Am liebsten wäre mir ich könnte die IP’s komplett ohne irgendein NAT durch schleusen. Hab das mit Outbound NAT und „do not NAT“ schon versucht. Geht auch nicht.
Ebenfalls frage ich mich, was ich eigentlich als Gateway für das 29er Subnetz nehmen muss, da das Gateway von der Transer IP auf WAN2 in einem ganz anderen Netz liegt…
Bei der NAT Variante hab ich die Interface IP von HNET genommen. Aber sobald ich BINAT einschalte, oder normales NAT - und dazu noch ein outbound NAT- , geht nix mehr.
Kann die zwei testweise vergebenen IP’s des 29er Subnetzes von extern nicht einmal anpingen oder so.
Echt eine seltsame Praxis dieses Providers. Hatte ich so noch nie.
Konntest du das damals lösen?
Viele Grüße und, es gilt glaub noch, ein gutes neues Jahr,
David
Hallo David,
leider kann ich dir da nicht helfen: in den 3 Wochen damals hat der
Aufwandsträger der Einrichtung ein Einsehen gehabt und doch einen Cisco
921 angeschafft als Router …
Schmackhaft wurde ihm das, weil er in dem beide Netzte (Verwaltung und
pädagogisch) abbilden konnte und nicht mehr zwei Router benötigte.
Damit hatte sich das Problem für mich einfach gelößt: weiter wie bisher,
nur eben nicht mehr mit einem alten Cisco sondern mit einem neuen.
LG
Holger
Hi,
manchmal sagen Netzpläne mehr als tausend Worte, weil den Beschreibungen ist nicht ganz zu entnehmen wieso es ein 2. WAN-Interface gibt und wo das Problem mit NAT oder nicht-NAT genau sein soll. Gemäß Network Address Translation — OPNsense documentation würde ich NAT erstmal deaktivieren („Disable outbound NAT rule generation“). Dann richtet man nur für das WAN-Interface, über das Clients mit privaten IPs Richtung Internet kommunizieren sollen, eine Outbound-NAT-Regel ein. Für alle anderen Schnittstellen/IP-Netze würde dann weiterhin ohne NAT gearbeitet, also schlicht geroutet. Dadurch kann der gewünschte Mischbetrieb erreicht werden. Das IP-Netz der Server mit öffentlichen IPs wird in beide Richtungen normal geroutet und alle anderen Clients werden bei Kommunikation Richtung Internet einer NAT unterzogen. Virtual IP, Proxy ARP, 1:1 NAT usw. braucht man dafür gar nicht.
Die Gateway-IP muss prinzipiell im selben IP-Netz sein wie die vergebene IP des Interfaces, worüber der Datenverkehr den Router verlässt. Dies gilt nicht, wenn es sich bei dem Interface um eine Punkt-zu-Punkt-Verbindung handelt (bspw. PPPoE, bestimmte VPN) oder wenn der Provider sich nicht an best-practice hält. Es gibt wohl (eher seltene Fälle), wo Provider einfach jedes Paket, was auf einem Interface vom Kunden reinkommt, auf Layer 2 weiterverarbeiten unabhängig davon welche Ziel-IP (Gateway-IP im Router des Kunden) im IP-Paket steht.
Jetzt wird’s spekulativ: Wenn die dein Provider ein /29er Netz genannt hat, wird er dies vermutlich als Transfer-Netz nutzen. Dann sollte er eine IP darin auch als Gateway-IP benennen, üblicherweise die erste oder letzte nutzbare IP. Gleichzeitig müsstest du mit ihm aber auch abstimmen, welche IP deine OPNsense-Box in dem Netz verwendet, denn dorthin muss er ja das IP-Netz deiner Server mit öffentlicher IP routen.
Sollte es zwei WAN-Schnittstellen geben, kann man in den Firewallregeln zum Akzeptieren des Datenverkehrs auch angeben, über welches Gateway (und damit WAN-Interface) die Pakete laufen sollen.
MfG Buster
Hi Buster,
vielen Dank für deine ausführliche Rückmeldung.
Ich schildere hier kurz das ganze Erlebnis…:
Das hatte ich genauso schon hinter mir wie du es beschrieben hast, bis ich, über viele Forenbeiträge inspiriert, den „Qutasch“ mit Virtual IP’s (Aliase, Proxy ARP) etc. ausprobiert hatte.
Einziger Unterschied zu deinem Vorschlag, der absolut hin haut: Ich hatte zu Beginn Hybrid Outbound eingestellt und ne Regel erstellt, dass er aus dem HNET Netz auf dem WAN2 Interface nicht NATet. Kommt dann bei first Match ja aufs gleiche raus.
Ich hab nach den ganzen Versuchen irgendwann gedacht entweder ich ich zu doof oder der ISP hat nicht bzw. falsch geroutet.
Nach zig Anrufen beim Provider und einer abschließenden Mail, in der ich alles geschildert und anklingen lassen habe, ob vielleicht keine oder falsche Routen gesetzt wurden, habe ich heute eine Rückmeldung bekommen, dass sie ihrerseits ein paar „Dinge“ „angepasst“ haben.
Hatte von meinen Traceroute Ergebnissen vorher zum Glück Screenshots gemacht und nach der Mail gleich nochmal nen Traceroute auf eine der IP’s gemacht und siehe da…Auf einmal sah alles ganz anders, bzw. wie gewünscht aus und nach 2 Minuten war in der Sense alles eingestellt → Nur die Outbound NAT Regel, dass nicht geNATet wird.
Weiß nicht wie viele Stunden ich nun verbraten habe, aber Ende gut, alles gut. IP’s sind erreichbar und Server können angepasst werden.
Vielen Dank dir und alles Gute,
David
Hi,
schön zu hören. Wenn man kurz vorm Verzweifeln ist und denkt die Physik müsste neu definiert werden, damit es funktioniert, dann ist es immer die beste Lösung, wenn ein Dritter um die Ecke kommt und seinen Fehler korrigiert. 
MfG Buster