Messages

1846

German - Deutsch / Re: 1:1 NAT und Portforward

« on: May 17, 2017, 03:50:46 pm »

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

1847

German - Deutsch / Re: [GELÖST] IPSec Bugs

« on: May 17, 2017, 03:45:21 pm »

@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

1848

German - Deutsch / Re: 1:1 NAT und Portforward

« on: May 17, 2017, 03:30:02 pm »

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

1849

German - Deutsch / Re: 1:1 NAT und Portforward

« on: May 17, 2017, 10:09:47 am »

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ß

1850

German - Deutsch / Re: [GELÖST] IPSec Bugs

« on: May 15, 2017, 10:47:56 am »

> 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ß

1851

German - Deutsch / Re: [GELÖST] IPSec Bugs

« on: May 12, 2017, 03:29:49 pm »

Ich verbrenn mir genauso ungern an Grunsatzdiskussionen die Finger wie Franco aber wie ist das zu verstehen:

"Am Ende ist das Warten aus Gründen der Stabilität weniger Aufwand für Nutzer, aber mehr Aufwand für Entwickler. Das bringt mich wieder zurück dazu, dass niemand dann updaten muss wenn Updates vorhanden sind. Und der Möglichkeit eine langfristige Balance zwischen beiden Varianten zu finden."

Natürlich bin ich nicht gezwungen dazu. Keinesfalls. Aber geschätzte OpenSource Philosophie hin oder her - wenn es Bugs oder Security Gründe gibt, dass ich auf eine neue Version updaten sollte - dann kann ich schlecht sagen: Oh bspw. 16.7 lass ich noch gut sein und bleib auf 16.1, weil das ist noch nicht so gut abgehangen und die Security Fixes lass ich bleiben. Und um das bleiben zu können, müssten ja alte (T-2? T-3?) alte Versionen ebenfalls gepatcht werden, damit man ruhigen Gewissens auf der alten Version bleiben kann. Ich glaube kaum, dass das dann für die Entwicklungsressourcen besser wäre, oder irre ich mich da?
Das ist glaube ich (?) auch der Kern von dem was Dirk schreibt. Ich update ja nicht zwangsläufig um "the latest and greatest" an Software zu bekommen, sondern eben um ein aktuelles OS/System zu haben ohne (bekannte) Lücken. Und dann auf dem Vorgänger oder Vorvorgänger zu bleiben aus Stabilitätsgründen ist bei einem System, dass ja Sicherheit bringen soll irgendwie ein ziemlich diamtraler Ansatz.

1852

German - Deutsch / Re: 1:1 NAT und Portforward

« on: May 12, 2017, 02:57:41 pm »

Die Frage per se hat so viele Ober- und Untertöne, dass ich lieber nachfrage. Was soll denn bitte genau erreicht werden? 1:1 NAT ist jetzt auch nichts anderes vom Prinzip her als ein Port Forwarding aller Ports einerseits und ein Outbound NAT andererseits miteinander kombiniert. Aber in der Beschreibung schwingen da viel anderen Sachen und Halbwissen mit, weswegen es sinnvoll wäre klar zu definieren, was denn von wo nach wo wie funktionieren soll.

Gruß

1853

German - Deutsch / Re: CARP und LAGG?

« on: April 07, 2017, 12:32:57 pm »

> sollte nach einiger Zeit (240 Sekunden?)

Nein, das sollte quasi sofort wiederhergestellt werden.

> Im Log fand ich dazu: "carp: demoted (pfsync bulk fail)"

pfSync nicht auf extra Interface konfiguriert? Es wird empfohlen, Sync wie eigenem Crossover Interface zwischen den beiden Geräten zu realisieren. Man kann es auch auf LAN laufen lassen, sollte es aber lieber über ein dediziertes Interface abbilden.

>  Ich möchte ungern ausserhalb des WebGUI mit sysctl irgenwelche zusätzlichen Tunables erstellen.

Das gehört aber zur Arbeit mit der Hardware und dem OS dazu. Es werden eben für einige Hardware Settings Tunables benötigt.

> Oder vielleicht sogar einen ganz anderen Lösungsansatz?

Erstmal müsste man dein Problem konkretisieren, dann gibt es vielleicht auch einen (anderen) Lösungsansatz.
Zudem hast du uns leider nicht erhellt, welche Version du bspw. einsetzt etc.

1854

German - Deutsch / Re: Kennwort exportiertes cert.p12 Zertifikat

« on: April 07, 2017, 12:29:43 pm »

Warum? Was ist das Problem mit der gespeicherten Daten?

1855

German - Deutsch / Re: Sicherheit von Smart Home / IoT-Devices

« on: April 07, 2017, 12:29:06 pm »

Wir werden IMHO noch viel mehr "böses" lesen, bevor es besser wird. Durch solche gehypte Buzzwords wie das von der Kanzlerin groß gelobte Industrie 4.0 werden wir eine Masse an IoT und sonstigen Gegenständen aus dem Alltag und Haushalt erleben, die eben "I4.0"-like einfach mal ne Netzwerkbuchse oder - noch schlimmer - WLAN spendiert bekommen. Leider wird das aber meist von Leuten designed, die bislang keinerlei Ahnung von Netzwerken, Infrastruktur und vor allem: Sicherheit, Authentifizierung und Autorisierung haben.  Bei vielen ist es damit getan, dass sie ihrem Gerät ne RJ45 Buchse und nen IP Stack spendieren. Dass solche Kisten dann aber plötzlich (planlos oder geplant) am Internet hängen ... nun davon haben wir ja schon den ersten Fallout gesehen. Standardpasswörter, in HW verdrahtete Logins, alte Cypher etc. die nicht nachgerüstet werden können, etc. etc. wird man nun leider noch viel häufiger antreffen, denn kein Hersteller will jetzt nicht mehr "smart" sein. Und daraus nun die Perlen zu ziehen, die sich wirklich ordentlich mit dem Thema beschäftigt haben wird schwer...

1856

German - Deutsch / Re: Kann man mit opnSense eigene DNS einträge erstellen (DynDNS ersetzen)

« on: April 06, 2017, 01:29:26 pm »

Warum sollte die Sense das nicht können?

Davon abgesehen, braucht es dafür OpnSense per se nicht wirklich. Du kannst die DynDNS Geschichten auch per DDNS (RFC2136) machen sofern die Domain, die die Einträge haben soll bei einem Provider ist (oder dir selbst), und das ordentlich unterstützt wird. Dann entfällt irgendein DynDNS Dienstleister und du machst es noch dazu mit deinem eigenen Domainnamen.

1857

German - Deutsch / Re: DMZ einrichten - Neuer Switch oder VLAN

« on: March 30, 2017, 10:47:30 am »

Ist natürlich ein wenig Glaubensfrage, aber ich hab in all meinen Jahren bisher noch immer keinen wirklich gelungen ausgeführten Angriff gegen VLAN Konfigurationen gesehen. Wenn der Switch nicht gerade völlig panne ist und die Konfiguration halbwegs durchdacht, bin ich der Meinung, dass das für den Einsatzzweck genügt. Ich weiß ja nicht in welchem Stil du was extern anbieten willst und ob das deine Heim-Leitung ist, aber ich würde behaupten wollen, dafür reichts dicke.

Grüße

1858

German - Deutsch / Re: DMZ hinter FritzBox die internes WLAN bereitstellt

« on: March 30, 2017, 10:07:53 am »

> Aus Sicherheitsgründen. So bin ich sicher, dass die FritzBox schon nur 443/TCP (und 80/TCP) an OPNsense weitergibt.
> Klar ist mehr Aufwand als der Exposed Host aber stört mich nicht, da nehme ich lieber den Tick mehr Sicherheit

Was hat das mit Sicherheit zu tun? Gefilter wird eh sinnvollerweise auf der Sense. Ob du vorher dem Guffelfilter oder dem NATting der Fritz Box mehr traust als einem Gerät dass du selbst baust und das tut was du ihm sagst, sei mal dahingestellt, aber Sinn macht es für mich nicht, ein Mehr an Sicherheit kann ich auch nicht erkennen. Denn nur weil du alles weiterleitest erlaubst du es an der Sense trotzdem nicht. Plus du hast unnötig höheren Komplexitätsaufwand wenn mal was an Ports dazukommt und bist bei Debugging immer an zwei Geräten dran. Da sehe ich keinen Gewinn.

> daher kein Problem.

Jein. Du nutzt trotzdem DHCP und verlässt dich so bei der IP Vergabe auf externe Geräte. Statische IPs booten schneller, sind weniger fehleranfälliger und man hat zusätzlich die externe Abhängigkeit raus, dass die Sense bzw. der DHCP dort laufen muss damit die VMs überhaupt sinnvoll laufen. Finde ich weniger sinnvoll. Ohne diese Abhängigkeit kann man problemlos auch mal eine Test VM oder eine neue VM deployen ohne dass man zusätzlich vorher Hand an die Firewall anlegen muss. Ich sehe da nur unnötige externe Abhängigkeit.

> sondern auch noch einen WLAN Accesspoint, der Strom zieht.

Dafür aber je nach AP auch wesentlich mehr Möglichkeiten. Zudem sind viele APs auch per PoE fütterbar (Strom) somit keine wahnsinnigen Killerverbraucher. Die Rechnung kannst du dann selbst aufmachen, ob dich die paar Cent für den AP arm machen Zudem wird die vorgeschaltete Fritzbox bei abgeschaltetem WLAN Modul auch weniger Strom verbrauchen, somit ist die Bilanz nicht ganz so schwarz. Und nur wegen umgerechnet ein paar Euro im Jahr eine schlechte(re) Lösung mit sich rumschleppen - da musst du auch deine eigene Arbeitszeit und sinnvolles Arbeiten mit einberechnen, was dir das wert ist.

> Die FritzBox einfach durch einen Router mit 2 Interfacen (DMZ und LAN) + WLAN zu ersetzen ist leider auch schwierig, da die FritzBox auch DECT macht....

Davon hatte ich auch nichts geschrieben, die Fritte kann vorgeschaltet ja problemlos Upstream Router/Gateway plus DECT machen. Ist ja kein Drama. Aber alles andere abschalten, WLAN aus, Ports 3-4 abschalten (oder Eco) etc. und du wirst sehen dass die Kiste auch weniger Strom braucht. Und die Sense als exposed Host dahinter und als richtige Firewall bauen.

> spricht eigentlich auch überhaupt nichts dagegen es so zu lassen oder?

Für mich persönlich spricht da alles dagegen. Weil es komplett verkehrte Welt ist. Man baut sinnvollerweise eine Firewall Architektur von böse nach gut auf bzw. von untrustworthy nach fully trusted. WAN/Internet ist dabei rote Zone, da glaube ich gar nichts. Ergo ist WAN draußen. Da die Fritte meist vom Provider kommt oder gestellt wird, gehört die für mich ebenso als WAN behandelt, ergo haben da auch keine LAN Clients oder sonstwas drin zu suchen. Bei der Fritzbox kann ich keinerlei Filter wirklich setzen. Das ist für mich keine echte Firewall sondern ein freundliches Bastelwerk. Heißt aber auch, hinter der Fritzbox ist alles plötzlich "fully trusted" und darf einfach mit dem Netz sprechen. Und jetzt setzt du dahinter plötzlich noch ne Zone, die eigentlich eher "partially trusted" ist. Also die nur begrenzt sicher ist, da sie aktiven Kontakt mit der Außenwelt hat. Wo du Traffic reinlässt. Und den leitest du vorher aber komplett durch deine trusted Zone durch. Sorry, das wäre mir (subjektiv) an der Stelle völlig abwegig vom Aufbau her.

Grüße

1859

German - Deutsch / Re: OpenVPN welcher Port?

« on: March 30, 2017, 09:45:47 am »

> Was verwendet ihr für OpenVPN?

1194/udp normal, 443/tcp für den Ausnahmefall, genau wegen

> Genauer gesagt geht es mir z.B. um Hotel-WLANs (auch im Ausland), öffentliche WLANs bei Starbucks usw.
> Was kann man denn noch empfehlen, was in den meisten public WLANs offen ist?

Im Zweifelsfall ist bei den meisten offenen Netzen nämlich aus genau diesem Grund außer 80/443 kaum was offen, sehr viele Betreiber keine Lust haben, dass man aus deren Netzen dann irgendwelche Mailbomben zündet o.ä.
Deshalb kann man sich meist nur auf 80/443 verlassen, dass das offen ist.

1860

German - Deutsch / Re: OPENVPN - Keine Paket Fragmentierung

« on: March 28, 2017, 03:48:09 pm »

Dazu wäre es schön wenn du überhaupt einmal das Problem beschreiben könntest, anstatt zu sagen, was du möchtest