Messages

1

German - Deutsch / Re: Zugriff interner Server auf Public IP der Firewall funktioniert nicht

« on: June 08, 2021, 08:42:45 pm »

Interessant, obwohl das ja auf der Hand gelegen hat, hab ich nie ganz tabula rasa mit den forwarding regeln gemacht.
Eventuell hätte das auch geholfen. Da ich mich aber mittlerweile mit der DNS Lösung angefreundet habe, habe ich jetzt auch keine Lust mehr nachträglich noch mehr zu debuggen.

2

German - Deutsch / Re: Zugriff interner Server auf Public IP der Firewall funktioniert nicht

« on: June 02, 2021, 11:05:05 pm »

> Wie hinzugefügt?
> Das ist irgendwie unklar.

Du kannst ja grundsätzlich ein Port Forwarding auf mehreren Interfaces zugleich einstellen (multi select).
nachdem meine regel nun an den Interfaces WAN und WEB war, hat es geklappt.

3

German - Deutsch / Re: Zugriff interner Server auf Public IP der Firewall funktioniert nicht

« on: June 01, 2021, 02:26:35 pm »

Okay, die Screenshots sagen eigentlich nur folgendes aus:

Ein Port Forwarding an der WAN Schnittstelle mit Ziel "This Firewall", Port 443, weitergeleitet an den Proxy auf Port 443.
Dann hab ich einfach die WEB Schnittstelle hinzugefügt. Das ist das Interface, mit dem die Sense im Webserver-Netz ist.
Nach dem Hinzufügen des WEB Netzes zu dieser Forwardingregel ging es auf ein mal. Wenn ich NUR das WAN Netz drin hatte, ging es trotz Reflection nicht.

Ich habe mich jetzt doch für den DNS Override via Unbound entschieden. Einfach weil es sauberer und durchsichtiger ist, wie du schon sagst.

Danke auf jeden Fall für deinen Input.

4

German - Deutsch / Re: Zugriff interner Server auf Public IP der Firewall funktioniert nicht

« on: May 31, 2021, 09:11:10 pm »

> Sagen wir lieber mal: 203.0.113.123/24  (--> https://datatracker.ietf.org/doc/html/rfc5735, IPv4 Doku Netze)

Geh ich konform mit.

> Bleibt nicht hängen, aber ist nicht definiert, wenn dein Port Forwarding/Redirection keine "NAT Reflection" aktiv hat. Ansonsten ist die Weiterleitung NUR von WAN AUS ANkommend erlaubt, aber nicht von innen. Daher passiert auch nichts.

Seltsam. Ich habe alle möglichen Kombinationen mit den NAT Reflection Einstellungen ausprobiert und nichts führte zum Ergebnis. Aber eventuell haben mir da weitere Firewallregeln gefehlt ?!?

Ich habe einen Weg gefunden, der bei mir funktioniert. In Anhang 1 meine DNAT Regel vorher, in Anhang 2 nachher.
Ich weiß allerdings auch nicht genau wie "optimal" das ist.

> Wenn die auf die Domain gehen - was sie sollten(!)

Tun sie!

> dann geht das über einfachen DNS Rewrite bzw. DNS Override in der Sense -> besserer Weg und direkter, weil dann der Host gleich mit sich selbst spricht.

Ja, das ist durchaus ein bequemer und auch sauberer Weg. Nur dass in meinem Fall der Web-Host mit dem Proxy sprechen muss, nicht sich selbst, da der Proxy SSL terminiert und der webserver nicht.

> Warum will man das vermeiden

Ganz einfach, weil dann gewisse DNS Informationen an verschiedenen Stellen stehen und man die bei Änderungen dann immer mit bedenken muss. Ich bin generell ein Freund davon an so wenig Baustellen wie möglich zu arbeiten.

5

German - Deutsch / Zugriff interner Server auf Public IP der Firewall funktioniert nicht

« on: May 30, 2021, 07:50:14 pm »

Hallo,

Folgendes Szenario habe ich:
Eine aktuelle OPNsense als Edge Gateway.
1 WAN (sagen wir mal 1.2.3.4)
1 DMZ (10.11.0.1/24) in dem 1 Reverse Proxy Server steht
1 WEB (10.11.1.1/24)
+ weitere Netze für Datenbanken zB.

Am Standort ist nur 1 Öffentliche IP verfügbar und gewünscht. Sämtlicher Traffic soll über das GW

Regeln:
- Je internem Netz (WEB, DB, DMZ) eine Outbound NAT Regel auf WAN mit Interface IP
- 2 Port Forwardings an WAN für HTTP und HTTPS an den Reverse Proxy in DMZ
- Schnittstellenregeln, die HTTP und HTTPS aus den Netzen erlauben

Problem:
- Externer Zugriff funktioniert wie gewünscht, DNAT leitet auf den Proxy weiter
- Zugriff nach draußen via SNAT geht, sofern die angefragte IP NICHT die externe IP der Firewall ist
- Möchte ein interner Server einen HTTP/S Request auf die externe IP der Sense machen bleibt der Traffic in der Sense hängen

Warum soll das funktionieren? Nun, viele Webapplikationen machen Self-Requests. Diese funktionieren in dem Zustand nicht. (Weil die A-Records der Domain auf die Sense zeigen) Was ich vermeiden möchte sind Split DNS Szenarios oder Hosts-Einträge.

Diverse NAT Reflection Einstellungen habe ich schon erfolglos durchprobiert.

Hat jemand ne Idee ?

6

German - Deutsch / Re: Wireguard Config: Anzeigefehler oder Firewallfehler

« on: March 01, 2021, 01:54:04 pm »

Soweit ich weiß können die Tunnelendpoints beide v6 sein und trotzdem v4 tunneln.

7

German - Deutsch / Wireguard Config: Anzeigefehler oder Firewallfehler

« on: March 01, 2021, 12:30:24 pm »

Moin.

Ich habe 2 Firewalls, die via wireguard connected sind.

FW1 steht bei mir zu Hause am DSL Anschluss (Dual Stack)
FW2 steht bei meinem Hoster im RZ (auch Dual Stack)

Beide Firewalls haben jeweils eine IPv4 Regel, dass sie miteinander kommunizieren können. Keine der Firewalls hat eine IPv6 Regel, die diese Connection erlaubt.

Bei beiden Firewalls verwende ich Host Aliases, die auf einen FQDN gehen, also periodisch aufgelöst werden von der Sense

Beide FQDNs reagieren auf DNS Anfragen via A und AAAA Records

Also, netztechnisch, sowie auflösungstechnisch wären v4 und v6 gleichermaßen möglich, firewalltechnisch ist momentan nur IPv4 allowed.

Jetzt zeigen mir aber beide Firewalls an, dass die Endpoints v6 sind (dark theme ist RZ, light theme ist zuhause)

Jetzt bin ich etwas verwirrt. Eigentlich dürfen die ja nicht v6 sprechen. Andererseits lösen die FQDNs alle auch nach v6 auf. Daher vermute ich einfach mal, dass hier ein Anzeige"fehler" vorliegt, weil ich mir irgendwie nicht vorstellen kann, dass eine v4 Regel auch v6 durchlässt.

8

German - Deutsch / Re: Unifi Controller unter Opnsense

« on: May 13, 2020, 08:17:09 pm »

Der Controller ist an sich nix anderes als eine Java Web Application mit Mongodb Backend.
Sowohl Java als auch Mongodb kriegst du leicht auf nem freebsd installiert. Dann lädt man sich noch den controller und schon hat man alle Zutaten.

Das komplizierteste ist dann nur noch die einzelteile zusammenzubringen. aber das kann man sich von der linuxversion größtenteils "abgucken" und portieren.

9

German - Deutsch / Re: OPNsense 20.1.3 - LDAP Group Sync funktioniert nicht mehr

« on: March 27, 2020, 07:24:18 pm »

Ja, das war der Übeltäter. Hätte ich auch selbst finden können, hab aber in Github nur nach offenen Bugs gesucht.

10

German - Deutsch / [GELÖST] OPNsense 20.1.3 - LDAP Group Sync funktioniert nicht mehr

« on: March 27, 2020, 05:48:28 pm »

Hallo,

ich habe vor einigen Tagen auf 20.1.3 aktualisiert. Lief, also hab ich mir nix dabei gedacht. Heute wieder versucht mit meinem LDAP User anzumelden. Ging nicht. Also bin ich per SSH auf die Kiste. Mein User hat einen pubkey eingetragen und somit konnte ich connecten. Sudo -> Reboot. Hatte gehofft das würde es lösen.
Danach kam ich noch nicht mal mehr mit SSH auf die Kiste. Ausgesperrt. Jetzt konnte ich nur noch über den Rootuser arbeiten.

Als Root im Webinterface merkte ich dann, dass mein LDAP User absolut keine Rechte mehr hatte. Damit war die Sache dann klar.

- Ich hab meinen eigenen LDAP Server geprüft, die OPNsenseAdministrators Gruppe ist noch da und mein User gehört ihr auch an
- In der LDAP Config sind Read properties und Synchronize groups aktiv; Limit groups steht auf besagter Gruppe OPNsenseAdministrators (alle Einstellungen passen - hat ja auch vorher funktioniert)

Ein Testlogin im Interface zeigte folgende Infos:

Code: [Select]

User: <username> authenticated successfully.
This user is a member of these groups:


Attributes received from server:
dn => uid=<username>,cn=users,dc=ldap,dc=home
objectclass => top posixAccount shadowAccount person organizationalPerson inetOrgPerson apple-user sambaSamAccount sambaIdmapEntry extensibleObject
cn => <username>
uid => <username>
uidnumber => 1000001
gidnumber => 1000001
homedirectory => /home/<username>
shadowlastchange => 17801
shadowmin => 0
shadowmax => 99999
shadowwarning => 7
shadowexpire => -1
shadowinactive => 0
shadowflag => 0
sn => <username>
mail => <username>@<userdomain>
authauthority => ;basic;
apple-generateduid => C43D5741-383E-4B44-82E0-08076E6EC0F1
sambasid => S-1-5-21-1146636376-2845143762-4183641674-1006
sambantpassword => DDDF4259372CCD72CE7FDD8E2F5B27EE
sambalmpassword => XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
sambapasswordhistory => 0000000000000000000000000000000000000000000000000000000000000000
sambapwdlastset => 1538054256
sambaacctflags => [U ]
displayname => <username>
userpassword => {CRYPT}$6$ICH_BIN_EIN_HASH_HOLT_MICH_HIER_RAUS
memberof => cn=administrators,cn=groups,dc=ldap,dc=home cn=Directory Operators,cn=groups,dc=ldap,dc=home cn=users,cn=groups,dc=ldap,dc=home cn=OPNsense Users,cn=groups,dc=ldap,dc=home cn=WiFi Users,cn=groups,dc=ldap,dc=home cn=OPNsenseAdministrators,cn=groups,dc=ldap,dc=home
loginshell => /bin/bash
Der User wird also auch ldap-seitig als in der Gruppe interpretiert - meines Erachtens. Und trotzdem funktioniert die Gruppenzugehörigkeit nicht mehr.

Ist das ein Bug, oder was kann das noch sein?

11

German - Deutsch / Re: OPNsense Usertreffen 2020

« on: December 16, 2019, 09:17:06 pm »

Hallo!

ich finde die Idee super. Wenn es Raum München ist bin ich auf jeden Fall dabei. Mitstreiter aus Nü/Fü/Er könnte ich nach Bedarf auch mitnehmen, wenn es denn solche hier gibt.

Zur Orga/Ablauf. Hat jemand von euch schon mal von dem Konzept des https://de.wikipedia.org/wiki/Barcamp gehört? Für eine überschaubare Runde bis 100 Personen wäre das mMn. die ideale Form.

Vorteile:

• Wer Workshops anbieten will, der kann das auf jeden Fall vorbereiten
• Wem spontan bei der Veranstaltung was einfällt, der kann auch gern eine Session geben
• Ausgearbeitete Präsi oder Laptop sind nicht unbedingt nötig, Labersessions sind gern gesehen
• Die Möglichkeit für Reverse Sessions ist gegeben (Hier sagt jemand zB. was für ein Problem er hat und wer dabei helfen könnte, oder fragt wer hat Erfahrungen mit Diesunddas)
• Wir brauchen nur Zeitslots für die Sessions, der Rest kommt von den Teilnehmern

12

German - Deutsch / Re: OPNsense in Docker

« on: November 11, 2019, 06:30:33 pm »

OPNsense und Docker leben momentan in völlig verschiedenen Welten. Zum Einen wird Docker auf FreeBSD momentan als 'broken' erachtet (https://wiki.freebsd.org/Docker), zum Anderen kann in einem Docker Container nur Software laufen, die den selben Kernel benutzt wie der Host.

Dein NAS läuft höchstwahrscheinlich mit Linux. Somit kann ein Container auf deiner NAS auch nur Linux-Software laufen lassen, weil ja ein Container nichts anderes ist als eine durch Kernelfunktionen abgeschottete Umgebung auf genau der Host-Hardware.

Mal etwas rumgesponnen, man wolle unbedingt OPNsense auf einem NAS in Containern. Wenn Docker auf FreeBSD wieder ordentlich lauffähig wäre, könntest du dir nen FreeNAS nehmen und OPNsense da reinvergewaltigen. Aber das ergibt dann überhaupt keinen Sinn.

13

German - Deutsch / Default Deny Rule greift, obwohl sie nicht sollte

« on: October 14, 2019, 10:39:21 pm »

Ich beobachte momentan, dass die default deny rule auf meinem LAN öfter mal anspringt, obwohl ich es nicht erwarten würde.
Mein LAN Interface hat eine statische IP von 10.0.0.1/24. Ich habe in der Firewall an LAN die " Default allow LAN to any rule".
Diese besagt: Aus dem LAN Network erlaube jeglichen Traffic.

Ich erwarte also, dass alles aus dem Netz 10.0.0.0/24 zum LAN Network gehört und somit ungehindert das LAN Interface passieren kann.

Dennoch werden einige Dinge geblockt und das Log sagt, es sei wegen der Default Deny Rule.

Beispiel:
10.0.0.209:57550 --> (Pfeil nach rechts im Log) 108.129.22.15:5223 (TCP)

Details:

Code: [Select]

__timestamp__ Oct 14 22:34:34
ack 230790626
action [block]
anchorname
datalen 200
dir [in]
dst 108.129.22.15
dstport 5223
ecn
id 5769
interface vtnet0
ipflags DF
label Default deny rule
length 252
offset 0
proto 6
protoname tcp
reason match
rid 02f4bab031b57d1e30553ce08e0ec131
ridentifier 0
rulenr 14
seq 1938655:1938855
src 10.0.0.209
srcport 57550
subrulenr
tcpflags FPA
tcpopts
tos 0x0
ttl 64
urp 730
version 4

Warum wird sowas geblockt?

IDS/IPS ist im Übrigen nicht aktiviert.

14

German - Deutsch / Re: Aliase erstellen nicht mehr möglich seit 19.7.5

« on: October 12, 2019, 09:06:27 pm »

Ach gott, die Abendmüdigkeit lässt einen die Suchfunktion vergessen :-D
Danke, somit erledigt.

15

German - Deutsch / [ERLEDIGT] Aliase erstellen nicht mehr möglich seit 19.7.5

« on: October 12, 2019, 08:35:09 pm »

Hallo. Seit dem Update kann ich keine neuen Aliases mehr anlegen und keine existierenden mehr bearbeiten.Das Content Input-Field nimmt keine Eingaben mehr an und wird immer leer submitted. Getestet auf 2 unterschiedlichen Instanzen mit 19.7.5.