Messages

151

German - Deutsch / Re: Probleme mit DMZ bzw. anderen Subnetze

« on: June 04, 2018, 09:25:25 pm »

Du hast auf dem LAN Interface eine Regel, die der Source "LAN_net" alle Services zu allen Destinations erlaubt.
Die Regel matcht sobald Du von einem LAN Client z.B. einen Host in der DMZ anpingst. Danach wird die Regelverarbeitung abgebrochen, d.h. die Deny-Regel auf dem Interface "DMZ" kommt gar nicht mehr zum Einsatz.

Generell blockt man den Traffic da wo er entsteht. Wenn Du mit der Deny-Regel arbeiten willst, müsste die also auf dem LAN-Interface liegen. Und dann auch vor der Allow-Regel.

Aber eigentlich ist das gar nicht notwendig, denn die Default-Deny-Regel blockt den Verkehr zwischen den verschiedenen Subnetzen wenn dieser nicht durch eine vorherige Regel erlaubt wird.

Um den LAN Clients den Zugriff auf das Internet zu erlauben, und den Zugriff auf die DMZ zu verbieten müsste die Regel auf dem LAN Interface m. E. wie folgt aussehen:

Interface: LAN
Action: Allow
Source: LAN_net
Destination: !Local_Subnets

Weitere Regeln sind auf dem LAN Interface nicht notwendig. Deny-Regeln für Kommunikation vom LAN_net zur DMZ auf dem DMZ Interface kannst Du löschen.

EDIT: Ich hatte vorher auch die Sophos UTM, und das man bei der OPNsense Regel pro Interface anlegen kann war für mich auch gewöhnungsbedürftig. Ist aber eine coole Sache wenn man es einmal verstanden hat

152

German - Deutsch / Re: Probleme mit DMZ bzw. anderen Subnetze

« on: June 04, 2018, 08:41:44 pm »

Kannst Du mal einen Screenshot vom kompletten Regelwerk inkl. der Deny-Regel machen?

Der Ping geht durch und wird zeitgleich in den Firewall-Logs als "Blocked" gekennzeichnet?

Hast Du evtl. eine Flow-Regel angelegt, die noch auf allen Interfaces liegt und auf Allow steht?

153

German - Deutsch / Re: Probleme mit DMZ bzw. anderen Subnetze

« on: June 03, 2018, 03:13:50 pm »

Hi,

der Fehler liegt in den FW Regeln.

Du hast als erstes eine Allow Regel mit Destination alles ausser die lokalen Subnetze (!Local subnets). Das erlaubt den Clients den Zugriff auf das Internet.
Danach folgt eine Allow Regel mit Destination Any. Das erlaubt dann den Traffic zwischen den Subnetzen.

Entweder richtest Du explizit eine Deny-Regel für die Kommunikation von einem Subnetz zu den anderen ein, oder Du löscht einfach die letzte Regel. Dann zieht die Default-Deny Regel.
Alternativ kannst Du auch die erste Regel löschen und bei der zweiten Regel das WAN Gateway angeben. Dann wird nur der Traffic über das Gateway erlaubt.

Generell würde ich die Regeln etwas detaillierter konfigurieren, und so wenig wie möglich "Any" verwenden.
Ich habe z.B. einen Alias mit allen privaten IP Adressen (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) eingerichtet, und setze den in Regel für die Kommunikation in Richtung Internet als invertierte Destination (sprich alles außer den Netzen). Zusätzlich habe ich für jeden benötigten Dienst eine eigene Regel bzw. in einem Alias zusammen gefasst, und gebe noch die WAN Gateway Adresse mit:

Gruß
Jas

154

German - Deutsch / Re: url blockieren

« on: June 02, 2018, 03:08:27 pm »

Eine URL blocken geht m. E. nur mit dem Proxy.

Eine komplette Domain blocken kann man mit der Firewall realisieren. Man legt einen Alias für die entsprechende Domain an und verbindet diesen mit einer Block-Rule in der Firewall. Hinter dem Alias können auch mehrere Domains liegen. Das muss aber manuell gepflegt werden.

Alternativ kann man die Domain auch mit dem DNS Resolver blocken, indem man ein Redirect für z.B. youtube.com anlegt. Das lässt sich aber leicht umgehen wenn der Client auch externe DNS Resolver nutzen darf, oder er die IP anstatt der Domain in die Adresszeile eingibt.

155

German - Deutsch / Re: Static Mapping kein WAN

« on: May 21, 2018, 02:08:08 pm »

Irgendwie seltsam, ja.
Was heisst denn "Standard FW-IPv4 LAN Regel"?

Wenn Du keine interne und externe Namen auflösen kannst, liegt das Problem vermutlich am DNS.
Ist die DNS Server IP, die per DHCP ausgegeben wird identisch mit der, die Du im Host manuell konfigurierst?
Nutzt Du die korrekte Subnetmask und Gateway wenn Du die IP manuell konfigurierst?
Eine entsprechende Regel für DNS (UDP/53) existiert in der Firewall für die Source "LAN Subnetz bzw. das "LAN Interface net"?
Was siehst Du denn in den Firewall Logs? Wird die DNS Anfrage geblockt oder was anderes?

156

German - Deutsch / Re: Static Mapping kein WAN

« on: May 20, 2018, 01:03:41 pm »

Hey Taste,

muss mich erst mal korrigieren, anscheinend habe ich da was falsch getestet.

Also, das Firewall Objekt "LAN Interface net" beinhaltet auch die manuell, nicht vom DHCP vergebenen Adressen. Mit diesem Objekt wird also das komplette Subnet erlaubt wenn man es als Source in einer Firewall Regel einsetzt.

Nun zu Deiner Frage.

...
Also  die Firewall erlaubt den Traffic per se für das "Lan net", was ebenfalls per Default alle IP-Adressen im Lan entspricht. Dann kann ich im DHCP IP-Reservierungen einrichten, die außerhalb der DHCP-Range liegen müssen! Letzteres habe ich für die angesprochenen Clients gemacht. Daher müssten dann diese Clients, die eine IP aus dem "Lan net" haben, auch ins WAN kommen, also nicht von der Firewall geblockt werden, richtig?

Korrekt. Nur erlaubt die Firewall das nicht per se, sondern man muss die Regel dafür einrichten.
So habe ich es auch: Mein LAN hat das Subnetz 192.168.1.0/24. Mein DHCP Bereich liegt von 192.168.1.128 - 254. Für meinen PC habe ich die IP 192.168.1.15 per Static DHCP Lease reserviert, also ausserhalb des DHCP Bereichs.
In der Firewall auf dem LAN Interface habe ich eine Regel eingerichtet, die der Source "LAN Interface net" den Service 80/443 mit Destination Extern erlaubt. Zusätzlich die gleiche Regel für DNS. Das funktioniert einwandfrei.

...
Ich habe testweise mal auf "Lan Adresses" mit der any Einstellung umkonfiguriert. Nach ein paar Sekunden, kam ich dann gar nicht mehr ins WAN ... ?!
Ich bin irritiert, über die Logik

"LAN Interface Adresses" gibt es nicht. Meinst Du vielleicht "LAN Interface Adress"? Das ist das Objekt für die IP Adresse des LAN Interface der OPNsense. Bei mir wäre das z.B. die 192.168.1.1. Damit erlaubst Du nur diese eine IP. Alle anderen aus dem Subnetz fallen nicht da drunter und werden dann geblockt. Entspricht also Deiner Beobachtung.

Gruß
Jas

157

German - Deutsch / Re: Static Mapping kein WAN

« on: May 19, 2018, 02:30:21 pm »

Hi,
sorry, hast Recht. Du schriebst ja dass die Firewall auf Grund des DHCP Eintrages "reagiert". Richtig, hat somit nichts mit dem DNS direkt zu tun.
...

Entschuldigungen sind unnötig. So ein Forum ist ja zum Fragen stellen und helfen da

...
Ich kenne die optimale Konfiguration noch so, dass man z.B. die Clients per DHCP Range konfiguriert z.B. .100-.200 und den Servern direkt die IP im System vergibt. Dadurch kann bei einem Fehler / Ausfall des DHCP der Server seine IP nicht verlieren, was wesentlich wichtiger ist als ein Client. Klar kann man auch verschiedene Ranges im DHCP vergeben, oder alle in einem Netz per DHCP versorgen und wichtige per Reservierung fest vergeben, aber das ist irgenwie noch so im Kopf. Mag sein dass es so nicht mehr aktuell ist bzw. korrekt, aber daher sprechen wir ja mal drüber .)

So kenne ich das auch und so machen wir das auch in der Firma, in der ich arbeite.

Wenn Du das so umsetzen möchtest, kannst Du einen Alias im OPNsense mit den manuell vergebenen IPs anlegen. Falls Du einen IP Bereich für die manuell vergeben IPs reserviert hast, kannst Du anstatt jede einzelne IP auch den Bereich im Alias eintragen. Das erspart Dir Pflegeaufwand falls ein weiterer Server hinzu kommt. Die Firewall-Regel für den entsprechenden Dienst kannst Du von der Regel für die DHCP Clients kopieren, und änderst nur die Source von "LAN Interface net" auf den Alias ab.
Oder, wie schon oben beschrieben, Du erlaubst direkt das komplette Subnetz anstatt des Objekt "LAN Interface net" in der bereits bestehenden Regel. Dann lässt die Firewall alle Clients aus dem Subnetz raus. Spart ebenfalls Pflegeaufwand und hält die Anzahl der Regeln klein. Aber aus Security Sicht nicht so gut, da die Firewall somit jede IP aus dem Subnetz durchlässt.

158

German - Deutsch / Re: Static Mapping kein WAN

« on: May 18, 2018, 10:48:31 pm »

Der Eintrag im DNS hat doch nix mit der Firewall zu tun. Das ermöglicht nur, dass die reservierten IPs immer per DNS aufgelöst werden können, auch wenn der Client offline ist. Bei einem normalem, dynamischen Lease wird der DNS Eintrag verschwinden sobald der Client offline und der Lease abgelaufen ist.

Ich finde Deine Konfiguration mit der manuell eingetragenen IP und der zusätlichen DHCP Reservierung auch etwas ungewöhnlich. Was willst Du damit bezwecken? Das die Clients auch bei ausgeschalteter OPNsense kommunizieren können? Dann kannst Du unter Windows die "Alternative Konfiguration" verwenden. Die zieht nur wenn der Client keine DHCP IP bekommt.

Das die OPNsense sich so verhält wusste ich auch noch nicht. Bin erst durch Deinen Post auf dieses Verhalten gestoßen

159

German - Deutsch / Re: Static Mapping kein WAN

« on: May 18, 2018, 07:09:15 am »

Hi Taste,

ich verstehe das jetzt so:

"...mit statischer IP im System konfiguriert..."

Du hast eine IP manuell auf Betriebssystemebene auf dem Client eingetragen. Sprich der Client oder Server arbeitet nicht als DHCP Client.

"eine Reservierung im DHCP eingerichtet"

Und Du hast zusätzlich eine Reservierung im ubound eingerichtet.

Wenn der DHCP Lease nicht aktiv ist, d.h. nicht aktiv von ubound ausgegeben wurde, wird die Firewall diese IP auch blocken, solange Du das "LAN interface net" als Source in den Firewall Regeln verwendest.

Wenn ich Deinen Aufbau richtig verstanden habe, musst Du eigentlich nur die Clients/Server auf DHCP umstellen und dann sollte alles gehen.
Gruß
Jas

160

German - Deutsch / Re: Static Mapping kein WAN

« on: May 17, 2018, 09:22:39 pm »

Hi Taste,

wenn Du deine Clients mit statischen IPs versorgt hast, also diese manuell auf Betriebssystemebene einträgst, ordnet die Firewall diese Clients nicht dem vordefiniertem Firewall Objekt "LAN Interface net" (oder wie auch immer dein LAN Interface heißt) zu.
D.h. in den Firewall Regeln darfst Du als Source nicht das Objekt "LAN interface net" nehmen, sondern mußt manuell das Subnetz über "Single host or network" angeben (z.B. 192.168.1.0/24). Dann dürfen allerdings direkt alle IPs des Subnetz ins WAN.

Alternativ kannst Du im DHCP Reservierungen für die Clients mit statischer IP anlegen. So mache ich das und das ist auch Best-Practise, behaupte ich mal.
Vorteil: Ändert sich z.B. der DNS Server bei Dir im Netz, braucht Du das nur im DHCP der Firewall anzupassen und alle Clients bekommen das über DHCP mitgeteilt.
Bei statischen Einträgen auf dem System müsstest Du die DNS Adresse auf jedem System manuell anpassen.
Gruß
Jas

EDIT: Stimmt so nicht -> Siehe weiter unten!

161

German - Deutsch / Re: Default Deny Route blockt LAN-WlAn-Bridge

« on: May 17, 2018, 08:43:30 pm »

Finde ich auch schade aber ich finde es gut, dass Du dein Ergebnis hier postest und den Thread nicht unbeantwortet lässt.

Generell finde ich es immer besser sich mit den Problemen zu beschäftigen und ggf. mit der Hilfe von anderen zu lösen. Denn so bekommt man das Wissen und wird besser.
Wenn man einen Punkt erreicht hat wo man nicht weiter kommt und nix funktioniert wie man es will, muss man sich natürlich überlegen was mehr Sinn macht. 

Auf jeden Fall alles Gute mit der IPFire.

162

German - Deutsch / Re: Default Deny Route blockt LAN-WlAn-Bridge

« on: May 14, 2018, 01:57:01 pm »

...

Richte eine temp. Any-Any Rule auf der Bridge ein um auszuschließen, dass die Regeln aus irgendeinem Grund nicht matchen.

Ja, damit klappt's. Aber das ist ja nach meinem Verständnis nicht so wirklich Sinn der Sache, oder?

...

Nein, natürlich nicht. Sowas dient nur als schneller und schmutziger Test um einzugrenzen wo der Fehler liegt. Ich gehe mal davon aus das Du keine Hochsicherheitsumgebung hast. Da kann man sowas mal machen

Wenn also die Any-Any Regel auf dem INTERN Interface für LAN und WLAN Clients funktioniert hat wissen wir nun, dass mindestens die DNS Allow Regel aus irgendeinem Grund nicht für WLAN Clients matcht. Ziel-Adresse und -Dienst sind für LAN und WLAN identisch, somit liegt es vermutlich an der Zuordnung des eingehenden Interfaces oder einer falschen Subnetz Größe, was auch den Routingversuch zwischen LAN und WLAN erklären würde.

• Schau Dir die DNS Regel noch mal an, ob da als Source das richtige Netz drin steht (INTERN net), und ob die Subnetzgrößen im DHCP Server und dem Interface INTERN übereinstimmen.
  
• Setz mal in der DNS Regel als Source ANY, und schau dann ob die WLAN Clients DNS machen können (ping google.de)
• Evtl. hätte man die beiden Optionen bei Tunables vorher setzen müssen, bevor man die Bridge anlegt. In diesem Fall hilft nur Bridge und DHCP löschen, und neu anlegen.
  

163

German - Deutsch / Re: Default Deny Route blockt LAN-WlAn-Bridge

« on: May 12, 2018, 03:46:12 pm »

Ich selbst habe keinen WLAN Adapter und Bridge an meiner OPNsense im Einsatz, daher nur ein paar Ideen wie Du den Fehler vielleicht finden kannst.

• Welches Interface hast Du denn unter "System: Settings: Administration -> Listen Interfaces" für den WebGUI Access angegeben, wenn Du sowohl aus dem LAN als auch WLAN dran kommst? Wenn dort die Bridge drin steht, ordnet die Sense den Traffic zumindestens hier korrekt zu.
  
• Welcher Adapter wird unter den DHCPv4 Leases bei den beiden Clients angezeigt? LAN bzw. WLAN oder bei beiden die Bridge?
  
• Aktvier doch mal das Logging in der Allow Rule um zu schauen, ob bei erlaubten Paketen über das LAN Interface die Bridge oder das LAN Interface angezeigt wird. Wenn dort das LAN Interface angezeigt wird, ist es korrekt das bei den geblockten Paketen über WLAN das WLAN Interface und nicht die Bridge angezeigt wird.
  
• Richte eine temp. Any-Any Rule auf der Bridge ein um auszuschließen, dass die Regeln aus irgendeinem Grund nicht matchen.
  
• Funktioniert HTTP(s) über das Tablet wenn Du die IPs direkt ansprichst?
  
• Und dann eine Frage die sich mir gerade stellt: wieso zieht hier überhaupt die Firewall Rule? Pi-Hole und Tablet sind doch im selben Subnetz?
  

ERGÄNZUNG: Schau mal unter System: Settings: Tunables. Dort gibt es zwei Optionen die sich so anhören, als könnten sie mit Deinem Problem zu tun haben:

net.link.bridge.pfil_member=1
Set to 0 to disable filtering on the incoming and outgoing member interfaces.

net.link.bridge.pfil_bridge=0
Set to 1 to enable filtering on the bridge interface

164

German - Deutsch / Re: Zugriff von LAN ins Internet bei opnsense HINTER FritzBox

« on: May 12, 2018, 02:41:59 pm »

Den Wunsch möglichst wenig Arbeit bei einem Routertausch zu haben kann ich nachvollziehen.
Und die Schmerzen beim Wunsch das Fritten-WLAN zu nutzen auch. 

Ersteres bekomme ich aber auch im OPNsense Routingbetrieb hin. Wenn ich die neue Fritte oder was auch immer eh anpassen muss um z.B. den exposed Host einzurichten, kann ich auch noch schnell ne Rückroute für das LAN Subnetz hinter der Sense einrichten.
Falls mein Kunde oder wer auch immer die Subnetze der Sense-LANs ständig ändert und/oder erweitert, kann man auch eine komplette Netz-Klasse als Rückroute (z.B. 10.0.0.0/8) auf der Fritte einrichten. Dann spart man sich das nachträgliche Anpassen und Erweitern der Routen.

Letztlich führen aber beide Varianten zum Ziel. Ich versuche jedoch NAT zu vermeiden wo es geht. Es ist und bleibt eine Krücke, und bietet im LAN keinerlei Mehrwert an Sicherheit. Die Fritte zeigt in ihrer SmartHome Übersicht auch nur die Sense an, da alle anderen Clients hinter der Sense bis auf deren IP für sie nicht sichtbar sind.

165

18.1 Legacy Series / Re: How do I get my IPv6 hosts into DNS

« on: May 05, 2018, 03:08:11 pm »

The workaround would be to use NATv6.

You really don't want to go there.

Yep, I don't want to

For me this is only a test of IPv6 in my privat LAN. It would be nice to use unique IPv6 addresses for all my clients, but it's not mandatory. I think it's also a question of time until OPNsense can handle dynamic prefixes.