Messages

Hallo Zusammen,

es ist schade wie schnell & oberflächlich ihr Euer Urteil über mich und unsere Firma fällt.

Schaut doch mal an folgenden Stellen:

- Referenzkunden
- Vorträge
- CVEs
- unsere eigene Konferenz https://mcttp.de
- Veröffentlichungen
- TV und Radio-Auftritte
- Gremien
- usw.

Nur weil wir eine blinkende und dunkle Page haben, sind wir nicht gleich Scam xD

PS: Danke für den Hinweis zu Techbeacon, den Link müssen wir entfernen.

Viele Grüße aus München
Flo

Blinkend und dunkel ist gut. Aber wir sind hier kein Webdesign Forum, daher lassen wir das mal...

Das einzig seriöse, was man als Unternehmen aus meiner Sicht schreiben könnte, wäre eine Distanzierung von dem Post hier. Um klarzustellen, dass das keine versteckte Werbeaktion war.

Da aber ein gerade neu erstelltes Konto, seinen ersten Beitrag so schreibt. Lässt das ganze nicht weniger nach unseriöser Werbung wirken.

Klappt aber nicht. Muss die /32 IP zusätzlich als virtuelle IP auf das jeweilige Interface, falls ja welches?

Nein aber die 184 in eine zusätzliche Policy. Du definierst den Tunnel nicht mit Quelle 184.0/24 sondern mit der /32er IP weil sonst der Tunnel in P2 nicht hoch kommt. Du sagst ja dass nur das /28er erlaubt bzw. remote eingetragen ist. Dann muss das auch bei dir als lokal drinstehen. Dann muss es outbound NAT geben auf die /32er IP und das lokale Netz /24 muss dann als zusätzliche Security Policy für die Verbindung eingetragen werden, damit der IPsec Prozess die Pakete aufsammelt und übers VPN schickt.

Cheers

Genau. Das 184. Netz ist nicht in Phase2, sondern als zusätzliche Policy.In Phase2 ist nur das 192.168.100.96/28 hinterlegt, damit kommt der Tunnel auch hoch.
Die OutboundNAT Regel dann auf das IPSec Interface oder WAN?

Um ehrlich zu sein, sieht die Seite für mich maximal unseriös aus.
Zudem wirkt es auf mich so, als würdest du da nur Werbung für machen.

Die Antwort hängt davon ab:

* was die Remote Seite für eine IPsec Konfiguration hat: VTI oder normale Phase 2 Logik?
* was die Remote Seite für Remote Netz konfiguriert hat. Das bestimmt, was du selbst eintragen kannst.

Dann wird aber auf jeden Fall zusätzliche Security Policies für IPsec gebraucht, sonst würde der IPsec nur traffic von der /32 aufsammeln, du willst ja aber, dass der 184er/24 eingesammelt und via VPN verschickt wird. Daher muss das Ursprungsnetz als zusätzliche Policy rein und in die eigentliche Phase das "vorgegaukelte" /32 als lokal. Und dann natürlich noch nen NAT was ausgehend den Kram via IPsec auf die /32 umsetzt.

Genau es ist kein VTI und die Remote hat nur das /28 Netz erlaubt. Zudem müssen nur Geräte aus dem 184.0 Netz in das 200.0 Netz, aber kein Zugriff in die andere Richtung.
Dazu habe ich bereits eine zusätzliche Policy angelegt, dass auch mein 184.X Netz über die VPN geht. Diese greift auch, da ein Pacettrace auf dem IPSec Interface, die Pakete anzeigt, welche von dem 184.0 Netz in das 200.0 Netz gehen.

Weiter scheint das Outbound NAT für die Pakete nicht zu greifen.
Ich habe die NAT Regel bereits auf dem LAN, IPSEC oder WAN Interface angelegt:
Quelle: 192.168.184.0/24
Ziel: 192.168.200.0/24
MappingIP: 192.168.100.97/32

Klappt aber nicht. Muss die /32 IP zusätzlich als virtuelle IP auf das jeweilige Interface, falls ja welches?


Danke euch!

Seite 1 . lan regel icmp zu ziel zb 10.10.10.10 erlaubt,

dann würde die regel greifen, durch den vpn bis rübe rzur seite zwei.

Und jetzt block nötig oder wnen nicht erlaubt, dann kommt es nicht durch?

Ganz genau.

Ich mache die Regeln selbst immer auf dem VPN Interface, auch wenn ich die Kontrolle für beide Firewalls habe.
So kann man auf einen Blick sehen, was per VPN rein kommt und was nicht.

Floating Regeln nutze ich garnicht, bevorzuge es die Regel da zu lassen, wo sie hingehört

Die Regeln greifen schon auf dem ersten Interface, wo die Pakete ankommen.

Beispiel:
LAN1: 192.168.1.0/4
Remote: 192.168.5.0/24

Nun soll LAN per ICMP an Remote dürfen.
Dazu muss zuerst der Datenverkehr auf LAN1 erlaubt sein, entweder hast du da dort schon eine Regel die z.B: ICMP an alles erlaubt oder legst explizit eine mit dem Ziel Remote an.

Dann brauchst du auf der Remote Firewall noch eine Regel, die als Quelle LAN1 ICMP in Remote erlaubt. Diese Regel wird auf dem Wireguard Interface angelegt, da dort die Pakete zuerst eintreffen.

[Folgendes ist bereits Umgesetzt:]

Hallo zusammen,
ich brauche bei folgendem Szenario mal etwas hilfe, ob/wie das überhaupt umsetzbar ist.
Es geht dabei um eine IPSec S2S Verbindung, die leider so vorgegeben ist, Wireguard etc. ist also keine Option.

Netze:
Mein LAN: 192.168.184.0/24
Zugelassenes Netz/Tunnel Netz: 192.168.100.96/28
Remote Netz: 192.168.200.0/24

Nun kann die Remote Seite nichts mit Paketen aus dem LAN Netz anfangen, wird das in der IPSec angegeben, kommt die Verbindung garnicht hoch.
Daher sollen alle Pakete von einer IP aus dem Tunnel Netz kommen, z.B. 192.168.100.97/32. Die VPN kommt hoch, allerdings bekomme ich kein NAT ans laufen.

Folgendes ist bereits Umgesetzt:
IPSec (Phase1+Phase2) sind aktiv.
Zusätzlich sind als manuelle Sicherheitsregel unter "Datenbank Sicherheitsregelwerk" das LAN -> Remote Netz hinterlegt.
Der Datenverkehr läuft über die IPSec Schnittstelle, ein Paketmitschnitt zeigt das.

Was nicht klappt:

Die Pakete auf dem IPSec Interface haben als Quelle noch die originale aus dem 184.0/24 Netz, nicht dem TunnelNetz.
Dazu wurde bereits entweder unter Outbound NAT:
Interface: IPSec
Quelle: 192.168.184.0/24
Ziel: 192.168.200.0/24
MapIP: 192.168.100.97/32

ODER
Unter 1:1 NAT:
Interface: IPSec
Typ: NAT
Externes Netz: 192.168.100.97/32
Quelle: 192.168.184.0/24
Ziel: 192.168.200.0/24

ODER
In den Erweiterten Sicherheitsregeln nur ein einzelnes Geräte, z.B. 192.168.184.10/32 hinterlegt.
Unter 1:1 NAT:
Interface: IPSec
Typ: BiNAT
Externes Netz: 192.168.100.97/32
Quelle: 192.168.184.10/32
Ziel: 192.168.200.0/24


Alles leider ohne Erfolg. Die Pakete gehen weiterhin mit einer 184.0 IP raus und werden dann von der Gegenseite natürlich verworfen.
Hat hier jemand eine Idee?

Vielen Dank!

Kein schlechter Vorschlag.
Mache doch dazu am besten ein Feature Request auf Github, da ist das denke ich am besten aufgehoben.

Is OPNsense affected. Seems that it's not using Tls-crypt-v2 when you configure the vpn via the gui

https://www.cve.org/CVERecord?id=CVE-2025-2704

Hello,

anyone has some more information about the current OpenVPN Server security issue?
The current OpenVPN Server Version seems like it's affected to the following problem:
https://www.tenable.com/plugins/nessus/214337

Does the OPNsense Team has an information if OPNsense is affected as well?
Security Audit in the current version, says yes (see screenshot)

Ah found it. Seems to work now.

Thank you a lot!

Thanks for the reply.

I already enabled strict_sni in my frontend. After that a connection from Apple Mail is working, but thunderbird and other clients not

Hello everyone,

at the moment I am trying to filter via SNI on HaProxy for my SMTPS and IMAPS connections.
Its all working fine when I select the default backend for SMTPS and IMAPS.

So I tried to create a condition where the SNI matches "smtp.mydomain.de" and "imap.mydomain.de".
Than no connection is possible.
The HAProxy is only in TCP Mode (working fine when default Backend is selected).

I already did a wireshark pcap on my WAN Interface, where the HAProxy is listening. The first TLS package show thats the SNI is set correctly "Client Hello (SNI=smtp.mydomain.de)".
So seems like HAProxy isn't respecting the SNI.

All Updates are installed.


Maybe anyone has an idea.

Das ist ein Punkt, was ich bei OPNsense wesentlich besser finde.

Das Ding macht eben das, was man einstellt. Und nicht irgendwelche Dinge, die der Hersteller mal für sinnvoll befunden hat, sobald man abweicht aber in einem Chaos enden.

Nachtrag:

Es scheint ein Windows-Problem mit dem OpenVPN-Client zu sein :'(
Parallel mit dem KDE Networkmanager auf einer Linux-Box getestet, da wird der DNS sauber übergeben und auch eingebunden.

Bin etwas Ratlos...

Welchen Windows Client verwendest du?