Topics

1

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 ?

2

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.

3

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?

4

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.

5

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.

6

German - Deutsch / 19.7.3 Firewall Änderungen

« on: September 02, 2019, 10:22:37 pm »

Hallo.

Seit 19.7.3 sieht bei mir die Firewall ganz anders aus und funktioniert nicht mehr so wie gewohnt. Beispielsweise funktioniert der OpenVPN Zugriff von außen nicht.

Es scheint so als hätte ich überall nur noch Quick Rules und kann in/out als Richtungen wählen (wie sonst nur bei Floating).

Ich bin sehr verwirrt, so ein Verhalten hätte ich aus dem Changelog nicht erwartet.

7

German - Deutsch / Routingprobleme (private IP geht übers default gateway ins internet raus)

« on: July 16, 2019, 08:27:37 pm »

Hallo, habe folgendes Problem:

Code: [Select]

traceroute 10.19.0.1
traceroute to 10.19.0.1 (10.19.0.1), 64 hops max, 52 byte packets
 1  opnsense.home (10.0.0.1)  2.594 ms  1.248 ms  1.178 ms
 2  mun1902aihr001.versatel.de (62.214.63.146)  22.724 ms  19.934 ms  21.089 ms
 3  62.214.36.181 (62.214.36.181)  19.324 ms  18.621 ms  19.813 ms
 4  62.214.38.59 (62.214.38.59)  27.491 ms
    62.214.38.57 (62.214.38.57)  25.986 ms
    62.214.38.59 (62.214.38.59)  28.468 ms
 5  fra020isp001.versatel.de (62.214.104.122)  28.676 ms
    fra020isp001.versatel.de (62.214.104.154)  31.074 ms  28.692 ms
 6  94.135.170.190 (94.135.170.190)  28.187 ms  28.949 ms  28.873 ms
 7  94.135.170.189 (94.135.170.189)  26.759 ms  28.963 ms  29.672 ms
 8  94.135.170.190 (94.135.170.190)  28.092 ms  28.071 ms  29.259 ms
 9  94.135.170.189 (94.135.170.189)  28.140 ms  28.975 ms  30.479 ms
10  94.135.170.190 (94.135.170.190)  31.575 ms  28.909 ms  29.683 ms
[...]
[...]

Scheint als würde Traffic an diese private IP (an alle aus 10.19.0.0/24) von der Sense über das Standardgateway ins Internet geroutet werden.

Vorher war dieses Netz ein getunneltes Netz innerhalb einer IPSec Verbindung, die auf der Sense schon nicht mehr existiert. Reboots brachten kein Ergebnis.

Werden Routen irgendwie gecached? Wie kriege ich das wieder raus? Normalerweise sollten ja dann die privaten Adressen nicht mehr übers WAN geroutet werden.


Routingtabelle von der Sense (v4):

Code: [Select]

Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            62.214.63.146      UGS      pppoe0
10.0.0.0/24        link#1             U        vtnet0
10.0.0.1           link#1             UHS         lo0
10.1.0.0/24        link#2             U        vtnet1
10.1.0.1           link#2             UHS         lo0
10.2.0.0/24        link#9             U      vtnet0_v
10.2.0.1           link#9             UHS         lo0
10.3.0.0/24        10.3.0.2           UGS      ovpns1
10.3.0.1           link#7             UHS         lo0
10.3.0.2           link#7             UH       ovpns1
10.4.0.0/24        link#11            U      vtnet0_v
10.4.0.1           link#11            UHS         lo0
10.5.0.0/24        10.5.0.2           UGS      ovpns2
10.5.0.1           link#8             UHS         lo0
10.5.0.2           link#8             UH       ovpns2
10.10.0.0/24       10.0.0.11          UGS      vtnet0
62.214.63.146      link#13            UH       pppoe0
92.117.252.123     link#13            UHS         lo0
127.0.0.1          link#4             UH          lo0
192.168.42.0/24    link#12            U      vtnet0_v
192.168.42.254     link#12            UHS         lo0



8

German - Deutsch / IPSec Firewallfrage

« on: July 12, 2019, 11:54:00 pm »

Ich habe 2 Sensen. Beide gegenseitig mit IPSec eingerichtet. Ist es normal, dass die Connection klappt, obwohl auf keiner Sense an den WANs (wo die äußeren Verbindungen aufgebaut werden) Regeln für ESP, ISAKMP und NAT-T existieren?

9

German - Deutsch / IPSec Phase 1 wird nicht angezeigt

« on: July 11, 2019, 01:18:32 pm »

Hallo.

Ich wollte gerade eine neue IPSec Verbindung hinzufügen. Nachdem ich die Phase 1 abgespeichert habe zeigt er sie mir jedoch nicht in der Liste. So kann ich auch keine Phase 2 hinzufügen. Ich verwende 19.1.10.

10

German - Deutsch / Podcast-Empfehlung

« on: May 23, 2019, 09:42:34 pm »

Hallo!

Oft kommen Leute her, die OPNsense verwenden wollen, weil sie Gutes darüber gehört haben. Sei es für ihr Unternehmen, aber auch für zu Hause, um den unsäglichen Plasteroutern den Kampf anzusagen.
Nicht jeder von euch ist schon ein Netzwerk-Profi. Und nicht jeder von euch möchte es werden oder tage - und wochenlang Bücher wälzen.
Deshalb denke ich, dass für manche ein Podcast vielleicht eine gute Möglichkeit sein kann morgens auf dem Weg zur Arbeit/Schule/Uni oder auf dem Rückweg, oder abends im Bett die Informationen akustisch aufzusaugen.

Dieser Podcast ist eine absolute und persönliche Empfehlung von mir um Grundlagen der Netzwerktechnik und Funktionsweisen des Internets unkompliziert und meiner Meinung nach auch sehr kurzweilig zu lernen.

Es sind lange Folgen und viele Folgen. Wenn ihr Interesse habt, schaut einfach mal rein. Ich perönlich hab mit keinem der Podcast Autoren was am Hut. Ich finde ihn tatsächlich persönlich absolut toll und empfehlenswert.

Selbst alte Hasen können sich hier noch ihr Wissen bestätigen lassen und die ein oder andere Anekdote abgreifen.

Wenn man dann in etwa weiß wovon die alten Hasen hier immer reden, wenn es um IP, VPN, Router, Firewall, MTU, Interfaces usw. geht hat man mit der OPNsense gleich noch mal mehr Spaß.

https://requestforcomments.de/

11

German - Deutsch / [Gelöst]Einem Interface eine IPv6 Adresse hinzufügen

« on: January 15, 2019, 12:39:23 pm »

Hallo!

Wie kann ich einem Interface eine weitere IPv6 Adresse hinzufügen?
zB. Trackt mein LAN das Präfix vom WAN und kriegt somit ne globale Adresse zugewiesen. Eine link local hat es ja eh automatisch. Ich würde jetzt gern zusätzlich noch eine ULA vergeben. Geht das über die GUI?
Virtuelle IPs scheinen nur mit IPv4 zu gehen.

12

German - Deutsch / [Gelöst] IPv6 RFC 7217 Adressen statt EUI-64

« on: January 09, 2019, 06:26:01 pm »

Hallolo!

Wie ich gerade gesehen habe generieren die Sensen ihren IID nach dem EUI-64 Verfahren. Das ist jetzt nicht so schlimm, als dass ich auf die Barrikaden klettern würde, aber mehr würde mir gefallen, wenn die Sense ihren IID nach RFC 2717 generiert.

Hintergrund: Nach EUI-64 beinhaltet der IID stets die MAC Adresse des Interfaces. Lieber hätte ich so eine "opaque stable address". Kann das FreeBSD?

13

German - Deutsch / 18.7.8 Outbound NAT kaputt ?

« on: November 23, 2018, 09:40:31 pm »

Hallo,

seit 18.7.8 verhält sich bei mir das ausgehende NAT fehlerhaft.
Aber nun mal im Detail:

Ich habe einen OpenVPN Server mit dem Tunnelnetz 10.5.0.0/24 und ein LAN mit 10.0.0.0/24
Um unterwegs in Hotels und öffentlichen Spots surfen zu können aktiviere ich ganz gern, dass der gesamte Datenverkehr über VPN geht. Damit ich dann auch richtig raus komme hatte ich bisher folgende Outbound NAT Regel:

Code: [Select]

Schnittstelle: WAN
Quelladresse: Einzelner Host oder Netzwerk 10.5.0.0/24
Quellport: Jeglich
Ziel invertieren: Ja
Zieladresse: Einzelner Host oder Netzwerk 10.0.0.0/24
Zielport: Jeglich
Statischer Port: Ja
Übersetzung: Schnittstellenadresse

Als neues Feature wurde im Changelog angegeben, dass im Outbound NAT jetzt auch die Netzwerke aus der Liste einfach eintragbar sind. Also habe ich folgendes verändert:

Code: [Select]

Schnittstelle: WAN
Quelladresse: VPN Netzwerk <-- NEU
Quellport: Jeglich
Ziel invertieren: Ja
Zieladresse: Einzelner Host oder Netzwerk 10.0.0.0/24
Zielport: Jeglich
Statischer Port: Ja
Übersetzung: Schnittstellenadresse

Das wollte ich dann so abschicken und bekomme die Fehlermeldung:

Die folgenden Eingabefehler wurden entdeckt:

Ein gültiges Ziel muss angegeben werden.

Jetzt dachte ich mir, was ist denn da los? Die Interface "VPN" ist im übrigen an ovpns2 gebunden.
Ich habe ebenfalls versucht das standardmäßig vorhandene "OpenVPN Netzwerk" zu nehmen. Es kam der selbe Fehler.

Na gut dachte ich mir, ändere ich eben Quelle UND Ziel:

Code: [Select]

Schnittstelle: WAN
Quelladresse: VPN Netzwerk
Quellport: Jeglich
Ziel invertieren: Ja
Zieladresse: LAN Netzwerk <-- NEU
Zielport: Jeglich
Statischer Port: Ja
Übersetzung: Schnittstellenadresse

Jetzt ging die Regel zwar durch, aber sie funktionierte leider nicht so, wie die alte Regel.

Ärgerlich, also wollte ich die Regel wieder auf Standard setzen (siehe ganz oben)
Und siehe da, geht nicht weil mal wieder das Ziel ungültig sei.

Was ist denn da los?

14

German - Deutsch / FreeRADIUS LDAP - Nutzer müssen in Gruppe sein

« on: September 28, 2018, 12:50:30 am »

Ich habe einen LDAP Server auf einer Synology DiskStation und habe OPNsense schon erfolgreich damit getestet.
Jetzt wollte ich meinen FreeRADIUS umstellen und auf Standardeinstellungen klappt es.

Wie aber konfiguriere ich jetzt, dass nur User einer bestimmten Gruppe gefunden werden?

So ist der Standard-UserFilter:

Code: [Select]

(uid=%{%{Stripped-User-Name}:-%{User-Name}})

Und so hab ich es vergeblich versucht:

Code: [Select]

(uid=%{%{Stripped-User-Name}:-%{User-Name}})(memberOf=cn=RADIUS Users,cn=groups,dc=ldap,dc=home)
Bin dazu noch ziemlich neu im Thema LDAP.

15

German - Deutsch / OpenVPN Firewall-Regeln - welches Interface

« on: July 13, 2018, 03:22:50 pm »

Hallo,

ich betreibe 2 OPNsense Instanzen unabhängig voneinander. Einmal zu Hause hinter nem Modem und ein mal bei Hetzner als vServer. Beide haben die aktuellste 18.1 Version.

Auf beiden laufen OpenVPN Server (Zwei daheim, einer beim Hoster - auch hier, völlig unabhängig von einander).
Auf jeder OPNsense sind die Server jeweils einem Interface zugeordnet (unter Schnittstellen)

Jetzt das Verwunderliche:

zu Hause:
Firewallregeln des zugeordneten Interfaces funktionieren, auch wenn in "OpenVPN" keine Regeln sind

Hoster:
Firewallregeln funktionieren NICHT. Ich muss explizit das "OpenVPN" Interface nutzen und wenn ich Traffic im zugeordneten Interface durchlasse, aber bei "OpenVPN" nichts drin habe, ist keine Kommunikation möglich.

Wann wird also was genommen?