Messages

OK dann wirklich mißverstanden. Das geht IMHO nicht ohne weiteres, außer du installierst dir ein DNS Server Package à la BIND, PowerDNS o.ä. und bindest dann entweder RFC2136 an oder schreibst dir / nutzt andere Skripte um die Eintragung von DNS zu erledigen.

Gruß

Du möchtest selbst DynDNS anbieten, verstehe ich das korrekt?

Du tust dir auf jeden Fall einen Gefallen, wenn du auch das LAN dann von Anfang an komplett wie ein "VLAN" behandelst und alle VLANs somit gleich. Dann hast du später keine Probleme mit "verhält sich anders" oder Überraschungen warum ein Port plötzlich einfach geht (weil er untagged ist) etc.
Und das Default VLAN 1 (und ggf. 0 soweit irgendwo als untagged VLAN genutzt) vermeiden. Spart ebenfalls Probleme :)

Sorry nicht wirklich.

Du "definierst" einfach irgendein Subnetz, welches nirgends aufliegt oder geroutet wird. Auf mehreren Interfaces, was per se schonmal nicht funktionieren kann. Und das soll dann auto-magisch für Dienstleister und Anwender funktionieren.

Ich habe schon komplexer Setups mit Sensen in Betrieb aber was du hier versuchst verstehe ich leider nicht ein bisschen. Deshalb auch meine Nachfrage ob du das mit einer Skizze o.ä. verdeutlichen kannst. Visio, Gliffy, Ascii-Art, ganz egal. Aber es macht für mich einfach überhaupt keinen Sinn was du hier versuchst?

1:1 NAT macht Sinn, wenn du bspw. auf einem externen Interface ein IP-Netz geroutet bekommst mit public Adressen und diese 1:1 auf ein internes Netz gleicher Größe oder einfach auf einzelne definierte interne IPs mappen möchtest. Was du hier versuchst verstehe ich nicht, da auf den WAN Adressen ja bereits interne Netze definiert sind. Da nochmals eins draufzulegen und das dann auch noch irgendwie via 1:1 NAT in ein weiteres internes Netz reinzumanschen kann ich nicht nachvollziehen ;)

Gruß

Da das "wie" sehr von den Hosts und dem Switch abhängt, kann man das pauschal nicht sagen. Im Prinzip kannst du aber einfach ein (zweites) VLAN auf dem Switch anlegen und entsprechende Netzwerkports bspw. als Default VLAN in dein neues VLAN konfigurieren, so dass das dort angesteckte Gerät dann automatisch im richtigen VLAN ist. die pfSense muss dann entweder ein weiteres physikalisches Interface auf dem Switch bekommen, das ebenso konfiguriert ist oder man konfiguriert den VLAN Tag zusätzlich auf das Interface, auf dem sie am Switch eh schon hängt.

Wenn du das einführst würde ich aber dazu raten auch das LAN gleich sauber in ein extra VLAN =! 0/1 (Default) zu verfrachten. Dann hat man nicht das Problem dass untagged und tagged Traffic ggf. auf dem gleichen Interface laufen und hat auch keine seltsamen Phänomene mit VLAN1.

Wenn deine Domain bei Mittwald von dort auf deren DNSen Dynamic DNS nach RFC 2136 unterstützt, dann benötigst du entsprechend den Key der Zone und die Details für welche Zone oder Unterzone du Einträge erstellen/ändern darfst. Dann werden diese einfach im Reiter RFC2136 unter DynDNS eingetragen und die Sense überwacht das WAN auf Änderungen und pusht diese bei Veränderung automatisch in den DNS.

OK das ist schön dass du das so siehst, beantwortet aber meine Frage nicht ;)

Du schreibst oben im ersten Post was von 10.96.100.2. Wo kommt also das Netz 10.96.100.x her und wie kommt das auf das WAN Interface (und welches)? Denn es kann logisch und technisch nicht sein, dass du das gleiche Netz auf zwei WANs ankommen haben möchtest.

OK wenn das die WANs sind - wo kommen dann die extern erreichbaren public IPs her, die du da drauf mappen möchtest? :)

Da kann ich Dirk nur beipflichten. Größe ist überhaupt kein Merkmal, es gibt auch große Häuser mit >100 Mitarbeitern, die mit 10MBit/s Leitungen herumgurken und kaum was machen genauso wie kleine agile Unternehmen mit <20 Leuten, die Gigabit Glasfaser haben und Proxy und Co einsetzen wollen. Beiden kann ich problemlos eine Sense anbieten für das was sie einsetzen wollen. Oftmals sind sogar schwergewichtige Pakete wie Content Filter etc. gar nicht wirklich notwendig, wenn man bspw. einen pfBlocker auf Layer 3 schon richtig konfiguriert, eine entsprechende IP Liste (mit aktiver Subscription) reinhängt und ab die Katze. Warum soll ich auch Deep Package Inspection machen, wenn ich solche Seiten gar nicht erst aufrufen kann? ;)

Und genau da ist man als Consultant, Specialist oder wie auch immer die hippen Bezeichnungen mitunter lauten gefragt, eben den Firmen zu verklickern "Hey natürlich könnt ihr <Firma> kaufen, habt Hardware X und Softwarelizenz Y als Kosten, aber ihr könnt das auch mit Sensen und angepasster Hardware machen! Da zahlt ihr Hardware + Integrationskosten durch die Firma."
Und bei den meisten, mit denen ich aus dem Umfeld gesprochen habe, ist eine Sense dann günstiger, selbst wenn sie monatlich noch nen Support oder Stundenkontingent einkaufen, weil es keine sinnbefreiten "Lizenzscheinchen" gibt, wo man eine Urkunde mit "+10 VPN Lizenzen" und Co bekommt. Das hat heute beim entsprechenden Berater gar nichts mehr mit "Kommerzielle Lösung" zu tun, sondern mit Support und Erfahrungslevel. Wenn der da ist und der Kunde das merkt, dann ist dem Wurscht ob da Cisco, Sophos oder *Sense draufsteht. Der will ja eh nur "dass es funktioniert".

Ich lese immer 10.96.100.5 - du hast leider zur Konfiguration der WAN Interfaces so gar nichts geschrieben. Daher kann ich dazu immer noch nichts sagen, da ich immer noch nicht weiß, welche IPs oder ggf. Netze deine WANs haben und wie dann das 1:1 NAT konfiguriert sein muss. Auch ob vor den WANs noch irgendwelche Router, Medienkonverter oder sonstwas stehen wäre relevant. Eine Skizze o.ä. könnte hier wirklich helfen.

Ein Screenshot der 1:1 Regel könnte ggf. auch weiterhelfen.

Grüße

Von dem Server weiß ich nichts bzw. ging aus dem Post bislang so nicht hervor.

Nichts desto trotz: Wenn auf irgendeinem WAN eine 1:1 NAT eingerichtet werden soll, sollte es da auch noch weitere Adressen geben als nur die WAN IP der Sense. Wenn diese geroutet wird, muss keine Virtual IP angelegt werden. Wenn die IP auf dem Gerät konfiguriert werden muss (da nur über Gateway erreichbar), dann ist diese entsprechend als VIP anzulegen (Alias oder CARP je nach Einsatzbereich des Geräts). Dann 1:1 NAT mit der externen IP und der internen IP des Servers und eine Firewall Regel, die den Zugriff erlaubt. Regel muss dann als Destionation NICHT die externe IP sondern die Server IP (intern) haben, da NAT VOR den Regeln ausgeführt wird.

Grüße

@Franco: Schade. Denn ich habe nichts ignoriert was du geschrieben hast, sondern hinterfragt. Wenn das eine "Gretchenfrage" sein soll, so be it. Wenn du eben selbst in den Raum stellst, dass ich dann ne Alternative brauche, dann stellt sich keine Gretchenfrage, sondern dann mache ich das vielleicht ein oder zweimal mit, danach bleib ich dann bei Alternativen. Und das finde ich an der Aussage und dem Umgang mit dem Thema schade.

Natürlich kann man sich beteiligen, es ist OpenSource etc. etc. das habe ich alles nicht in Abrede gestellt. Nur wenn ich das Projekt eben außer als Bastellösung (und das ist positiv gemeint) im privaten oder (sehr) kleinen Gewerbe einsetzen will, dann brauch ich als guter Dienstleister eine Rollback Strategie. Und da muss ich dem Post von mimug widersprechen, das machen NICHT nur Dienstleister die 150€ verlangen, sondern alle die das ganze ernst nehmen und ernsthaft gegenüber ihren Kunden betreiben. Denn einem Kunden behandle ich ehrlich und da gehört auch Offenheit dazu. Also kehre ich offene Bugs oder Security nicht unter den Teppich mit "muss man noch warten" etc. Nur weil etwas OpenSource ist, heißt das für mich nicht Bastellösung.

> Das ist eher ein Henne-Ei-Problem. Stabile Software und warten bis User kommen oder hier und da ein Bug und dafür eine stetig wachsende Userbase? Wie du's machst is' verkehrt.

Auch das sehe ich nicht. Wenn ich eben noch nicht die Userbase habe und auch die Entwicklerkapazität nicht, dann mache ich eben auch keine Releases mit festen Daten, gerade wenns Major Releases sind mit ziemlich großen Umbauten untendrunter (neues FreeBSD bspw.). Und da muss ich eben sagen, kam mir bei unseren Tests das ganze 17.1 Release ziemlich überhetzt vor. Selbst die angesprochenen großen Projekte wie Debian sagen da "when it's done" und das aus gutem Grund.

Genau das war meine Frage, ob das nicht mehr Sinn macht, als sich in die Erklärungen von oben zurückzuziehen (altes Release bleiben, zurückrollen, Alternative etc.). Das alles bräuchte man nicht, wenn das neue Release mehr Zeit hat zu reifen und nicht zum Termin raus muss, rollt es vielleicht auch einfach glatter als jetzt. Aber das mag mein Empfinden und Verständnis sein. Bevor das in irgendwelche Beschuldigungen ausartet was nicht meine Intention war, lass ich es an der Stelle ebenso bewenden mit meiner Anregung über das Release Modell (und Untersütztung der Vorgänger Version) nachzudenken. Mehr nicht :)

Also hat der Server oder die Appliance 4 WAN und 1 LAN Interface mit 6 VLANs, ist das korrekt?

WAN 1 IP Adresse 10.96.100.2 < (1:1)> Netzwerk 1 192.168.100.100
WAN 2 IP Adresse 10.96.100.2 < (1:1)> Netzwerk 1 192.168.100.100

Sowohl für WAN 1 und WAN 2 waren Virtual IP

Resultat - alle Anfragen gehen an die OPnsense nicht an die Ziel IP

Port Forwarding wurde versucht in Form von
WAN 1 IP Adresse 10.96.100.2 Port 21< 1:1NAT > Netwerk 1 192.168.100.100 Port 21
WAN 2 IP Adresse 10.96.100.2 Port 21< 1:1NAT > Netwerk 1 192.168.100.100 Port 21

Resultat das kam an, FTP kam aber nicht zu stande es kam die Fehlermeldung 425 vom Zielserver (Netzwerk 1)

Firewall: bei WAN 1 und WAN 2 als auch Netzwerk 1 waren erlaubt "Any!"

Es kam so fragend daher weil ich eigentlich keine Probleme mit Natten hatte bis zu dem Zeitpunkt.
Das 1:1 NAT lief vorher auf einer WAN schnitstelle (WAN 3) als ich es dann umgezogen habe also nur
WAN 1 IP Adresse 10.96.100.2 < (1:1)> Netzwerk 1 192.168.100.100
ging es schon nicht mehr.

Wenn man alles probiert und mit Wireshark dann ganz andere ergebenisse bekommt als man erwartet wird man irgendwann nervös bzw. unsicher.

Sorry aber das macht gerade bei mir überhaupt keinen Sinn.
Was ist mit WAN1 und WAN2 gemeint?
Warum auf dem WAN private Adressen?

Du lieferst leider gerade überhaupt keine Details zur Infrastruktur, nur dass es nicht so funktioniert wie du willst ;) So kann ich zumindest aber überhaupt nicht herauslesen, was und warum es nicht funktioniert.

Gruß

> Erfüllt die Software im letzten Stand alle Laufzeitkriterien für mein Umfeld?
> Nein, dann verwende ich eine ältere Version, ggf. Bug Report wenn es wichtig ist.

Auf alter, unsicherer Version bleiben ist im Business Umfeld eher tödlich für einen Dienstleister. Wenn dann tatsächlich was passiert und der Kunde hinterfragt warum, ist man geliefert.

> Kann ich aus sicherheitstechnischen Bedenken nicht die ältere Version einsetzen, muss ich auf eine geeignete alternative Ausweichen.

Und was wäre das dann?

> Ich finde es fatal wenn nur gefordert wird. Habe noch nicht mal Rückmeldung bekommen ob die beiden gemeldeten Probleme in diesem Thread beseitigt wurden, um die sich offensichtlich gekümmert wurde.

Nicht falsch verstehen. Ich fordere hier gar nichts. Ich fand nur die Aussage "man kann dann die alte Version ja länger einsetzen" ein wenig mißverständlich. Wenn ich weiß, dass bspw. 16.x weiter upgedated wird wegen Sicherheitslücken - ja dann kann ich die weiter einsetzen. Wenn nicht, bin ich quasi "genötigt" auf die neue Version zu gehen, die mir ggf. Probleme macht um weiter die Produktsicherheit und die meines Netzes das ich damit sichere nicht zu gefährden. Für privat o.ä. mag das dann ein gangbarer Weg sein, aber gerade wenn ich an Business Umfeld denke, ich das eben kein gangbarer Weg. Und da mir immer wieder gesagt wurde und wird, dass opnSense auch auf dieses Feld gerne zielt, fand ich den Satz ziemlich irreführend.

@fabian: Natürlich ist es ein Problem sowohl der Manpower als auch des Testumfelds. Nur wenn ich dann hinterfrage bzw. positiv kritisiere (mir liegt es fern einen Flamewar oder sonstwas zu starten), ob bspw. die momentane Vorgehensweise mit fixen Releaseterminen etc. sinnvoll ist, solange man weder die Manpower noch die Userbase für breites Testing hat, und ich lese dann, dass das aber doch gut so ist, dann hege ich da doch Zweifel an der Aussage.

> Ich finde es fatal wenn nur gefordert wird. Habe noch nicht mal Rückmeldung bekommen ob die beiden gemeldeten Probleme in diesem Thread beseitigt wurden, um die sich offensichtlich gekümmert wurde.

Das ist natürlich erst recht schade, dass dann erst gefragt wird und dann so wenig Feedback kommt.

Wie gesagt mein hinterfragen ist nicht böswillig oder Streiterei, aber wir evaluieren gerade opnSense auch für diverse Kunden und da es dabei meist Firmenkunden sind, halte ich das gesagt eher (auch für uns) dann für bedenklich. Was nicht heißt, dass wir - und ich selbst - nicht möchten, dass das Projekt besser wird. Ich habe gerade eine Test Appliance freibekommen, die ich jetzt gern mit opnSense bespaße und rückmelde was ich kann. :)

Gruß