Messages

Ich habe es gelöst, indem ich die Auto-Maskierungsregel herausgenommen habe.

Vielen Dank trotzdem!

Eine Situation, die mich verwirrt, ist folgende: Die OPNSense maskiert den Traffic zur Gegenseite mit dem Dummy-Netz 10.10.12.1, obwohl die Anfrage tatsächlich aus dem Netz 10.10.0.0/24 stammt. In den meisten Fällen ist das kein Problem, aber wenn die Kommunikation zwischen Domain Controllern über Tunnel hinweg stattfindet, darf das Netz unter keinen Umständen maskiert werden. Wie kann ich der OPNSense beibringen, dass das Netz 10.10.0.0/24 in Richtung 192.168.0.0/24 (Tunnel zur Gegenseite) nicht hinter 10.10.12.1 maskiert werden soll?

Freundliche Grüße

Verstanden, vielen Dank!

Hallo zusammen,

vielen Dank!

Du kannst die Tunnel-Adresse nicht aus demselben Netz nehmen wie dein LAN.

Das war der Grund. Nun habe ich allerdings ein Verständnisproblem. Ich möchte für die OPN-Sense Seite die 10.10.0.0/24 als lokale Seite eintunneln. Was hat es mit dem Tunnel Interface auf sich? Muss ich dort ein Dummy-Netz eintragen?
Bei Ipsec definiere ich auf beiden Seiten lokale und remote Netze. Ist das bei Wireguard im OPNSense anders?

Freundliche Grüße

Hallo zusammen

ich wende mich an Euch, da ich auf meiner OPNSense-Installation auf ein Problem gestoßen bin:

Sobald ich einen Wireguard-Tunnel aktiviere, scheint das LAN-Interface nach einem Neustart der OPNSense nicht mehr ordnungsgemäß zu funktionieren. In diesem Zustand ist es nicht möglich, das LAN-Interface anzupingen. Die einzige Lösung, um das Interface wieder erreichbar zu machen, besteht darin, mich über die Konsole anzumelden und alle Dienste neu zu laden.

Jegliche Anregungen und Ideen sind willkommen.

OPNsense 23.1.7_3-amd64
FreeBSD 13.1-RELEASE-p7
OpenSSL 1.1.1t 7 Feb 2023


Vielen Dank im Voraus für die Unterstützung.