Messages

1

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

2

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.

3

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.

4

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.

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 / Re: Internetzugriff OPNsense als Exposed Host

« on: July 21, 2019, 11:23:09 am »

Also wenn du von der Sense nicht mal die Fritz Box erreichen kannst, dann stimmt schon mal was nicht mit den Adresseinstellungen auf einem der Geräte. Hast du in der Fritzbox auch die korrekte Netzmaske gesetzt? Wie sehen da generell die Einstellungen aus?

8

German - Deutsch / Re: Internetzugriff OPNsense als Exposed Host

« on: July 19, 2019, 12:43:55 pm »

Sieht erstmal vernünftig aus. Zumindest von der OPNsense Seite. Wie sieht es auf der Fritz Box aus?

9

German - Deutsch / Re: Internetzugriff OPNsense als Exposed Host

« on: July 18, 2019, 08:02:43 pm »

Bitte mehr Infos. Gern auch Screenshots von:
- der IP Konfiguration
- den Outbound NAT Regeln
- den Firewallregeln
- der Routingtabelle

Was sagt der Output des Ping Commands genau?

10

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

« on: July 17, 2019, 11:57:19 am »

> Richtig, aber für die Einhaltung davon bist du zuständig
Alles klar, das hilft schon mal.

> An deinem Trace wundert mich eher, dass der ISP es so lange weitergibt und nicht blockt!
Erstens das und zweitens, dass die letzen beiden Router mit dem Paket Pingpong bis zur TTL spielen.

11

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

« on: July 17, 2019, 09:52:32 am »

Eventuell weil das Default Gateway eine öffentliche IP Adresse ist, und private Adressen eigentlich nicht über das Internet geroutet werden sollten. Aber ich sehe gerade das geschieht trotzdem. Und mein dämlicher Anbieter routet das natürlich selbst auch weiter...
Aber dann ist das wahrscheinlich einfach so ...

12

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



13

German - Deutsch / Re: IPSec Site2Site opnsense <-> opnsense Firewallfrage

« on: July 16, 2019, 01:52:20 pm »

Wie ich gerade erfuhr werden automatische Firewallregeln gesetzt. Es gibt auch eine Option dies zu deaktivieren. Standardmäßig scheint die Option allerdings aktiv zu sein. Ab 19.7 werden diese automatisch angelegten Regeln im Bereich Firewall auch sichtbar sein. Die Dokumentation sollte dann einfach mal aktualisiert werden. Das werd ich nach dem Release einfach mit nem PR gegen die Doku anstoßen.

https://github.com/opnsense/core/issues/3572

14

German - Deutsch / Re: IPSec Site2Site opnsense <-> opnsense Firewallfrage

« on: July 15, 2019, 12:54:23 pm »

Sorry, ich will da noch mal nachhaken, weil mir das keine Ruhe lässt.
Werden tatsächlich automatische Firewallregeln für IPSec angelegt, wenn es aktiviert ist? Denn ansonsten läuft gewaltig was schief bei mir.

15

German - Deutsch / Re: IPSec Site2Site opnsense <-> opnsense Firewallfrage

« on: July 13, 2019, 09:58:55 am »

Die Sense A ist ein vServer mit statischer IP, Sense B geht über VDSL mit dynamischer IP ins Netz.

In A ist bei IPSec die Remote Adresse mit der dyndns Adresse von B konfiguriert, sowie der Haken bei dynamic gateway gesetzt.

Beide Sensen machen IPsec über ihre WAN Interfaces. Was mich jetzt stört oder zumindest wundert ist, dass die IPSec Verbindung und die Tunnel funktionieren, obwohl in der Firewall weder bei A, noch bei B die nötigen Allow-Regeln gesetzt wurden für ESP, ISAKMP (UDP/500) und NAT-T (UDP/4500)

Es ist so, als würde der Fakt, dass ein IPSec eingerichtet ist automatisch Firewallregeln erstellen, die die Verbindung zulassen.