Recent posts

#1

Zenarmor (Sensei) / Re: Zenarmor and local hostnam...

Last post by Vilhonator - Today at 01:57:34 PM

You need paid subscription (like home which is 10€ a month) for it.

If you have paid subscription, then here are steps I could find.

• Go to Settings -> DNS Enrichment.Toggle on Perform real-time DNS reverse queries for local IP addresses. Under DNS Enrichment for Reports, add the IP address of your local DNS server. Save your changes and restart the Zenarmor engine from the dashboard
• Go to Services -> Unbound DNS -> Overrides in your OPNsense UI.Add Host Overrides for your client devices to map their names to their static IP addresses.
• Go to Services -> Unbound DNS -> Overrides in your OPNsense UI.Add Host Overrides for your client devices to map their names to their static IP addresses.
• Ensure you haven't accidentally masked your IP addresses. In the Zenconsole, check your Privacy Settings and make sure Anonymize local IP address is toggled OFF.
• If you are still seeing IPs or MAC addresses, you may need to clear your reporting database/cache to force a fresh look-up using the new DNS settings.

If that fails, then contact zenarmor support for further guidance.

Anyway, since you didn't mention wether you are using free version or not, I assume you are using free version and that's why it doesn't work

#2

German - Deutsch / Re: Unbound unter OpenVPN

Last post by viragomann - Today at 01:48:35 PM

Die VPN-Client nutzen die WAN IP nur für die VPN, nicht für andere Services, solange das nicht auf den Client ausdrücklich so konfiguriert wird.

Ich nehme an, du routest sämtlichen Traffic der Clients über die VPN, um diesen zu filtern?
Dann sollte auch ein DNS-Server gepusht werden, wie schon erwähnt. Ansonsten, würden sie bspw. einen öffentlichen DNS nutzen, würde dieser natürlich auch über die VPN und zum WAN raus geroutet werden. Ist das, was du meinst?
Dann hast du von ausgehenden DNS-Verbindungen gesprochen und ich habe an eingehende gedacht.

Wenn du das DNS der Client in den Griff bekommen möchtest, bedenke auch, dass diese DoH nutzen könnten. Da braucht es also auch Firewall-Regeln, die das unterbinden.

#3

German - Deutsch / Re: Unbound unter OpenVPN

Last post by trixter - Today at 01:40:11 PM

Nein, wie kommst du darauf?

Naja, einfach, auf welchem Interface läuft der Anmelde-Dienst?

Hintergrund: ich möchte auf WAN nicht unbound, sondern Adguard antworten lassen, um Inhalte auch für Clients zu blocken, die nicht hinter der FW sitzen.
Dazu muss unbound auf WAN allerdings die Klappe halten.

#4

German - Deutsch / Re: OpenVPN-Einrichtung: Probl...

Last post by viragomann - Today at 01:33:29 PM

Nach einigem Nachforschen mittels Online-Portscannern bin ich darauf gestoßen, dass der OpenVPN-Port 1194 von außen her nicht erreichbar, also geschlossen ist.

Vorsicht mit Port-Scanner bei OpenVPN.
Ich nehme an, du hast den OpenVPN Server für UDP konfiguriert, was Standard ist. Kaum ein Portscanner prüft aber UDP. Jedenfalls dann nicht, wenn du es nicht explizit auswählen kannst.

Anstatt einen Portscanner zu vertrauen, würde ich in OPNsense ein Packet Capture am WAN für Port 1194 laufen lassen, während ich von außen einen Zugriff mittels OpenVPN Client versuche.
Da solltest du ein Request-Pakete sehen, und funktioniert der Server, auch Responses.
Kommen keine Responses zurück, überprüfe Firewall-Regeln und die Server-Konfiguration sowie das OpenVPN Log.

Finden sich im Capture schon keine Request liegt das Problem außerhalb der OPNsense, bspw. vorgeschalteter Router, ISP od. beim Client.

#5

German - Deutsch / Re: Unbound unter OpenVPN

Last post by viragomann - Today at 12:58:45 PM

Das OpenVPN-Interface, naheliegenderweise.

Das setzt aber voraus, dass Unbound auf allen Interfaces lauscht.
Möchte man das nicht, und die OpenVPN Server IP als DNS bereitstellen, muss der Instanz ein explizites Interface zugewiesen werden, damit es in Unbound auswählbar ist.

Aber den VPN Clients ist es egal, ob sie ihre Anfragen auf die Server IP oder sonst eine richten. D.h. es könnte auch jede beliebige andere Interface IP sein. Sie müsste nur den Clients über die OpenVPN Option gepusht und der Zugriff erlaubt werden.
Ich verwende jedenfalls eine andere Interface-IP.

Kernfgrage : Auf welchem Interface laufen die Unbound-Anfragen für OpenVPN - meine Vermutung ist, dass das WAN hierfür verwendet wird.

Nein, wie kommst du darauf?

In der OpenVPN Server Konfiguration gibt es die Option "DNS Servers", mit welche angegeben wird, welchen DNS die verbunden Clients nutzen sollen.
Dieser Server wird dann am Client der virtuellen VPN Schnittstelle zugewiesen.
Steht da nichts, nutzen sie ihren Standard-Server, glaube ich jedenfalls. Ich denke nicht, dass der OpenVPN Server die eigene Interface-IP an die Clients verteilt, wenn hier kein DNS eingetragen ist.

Wenn man nun DNS für die VPN-User braucht, unbound aber nicht auf WAN veröffentlichen möchte (aus genannten Gründen)... Was ist die eleganteste Methode?

Keine Firewall Regel am WAN hinzufügen, die DNS erlauben würde.

#6

26.1, 26,4 Series / Re: Best practices for migrati...

Last post by Vilhonator - Today at 12:55:53 PM

The CSV export/import tool should fully preserve things literally as they are. There's always a chance things get broken because one thing or other, so it is good practice to check and make sure, rather than just expect it to work.

Import tool should work just fine, but it is still good idea to backup and make sure. In short, better safe than sorry

Also if you feel more comfortable with old rule interface thing, you can stick with it and leave the new interface thing untouched (the old interface section still works just fine, new one is there for people to try out)

#7

High availability / Re: Not able to manage HA back...

Last post by relvy - Today at 12:55:46 PM

> To also catch the case if the primary is the backup to the following:
> Say you want to access the backup using management VLAN IP, on the primary add both management IPs to an alias. I call it FW1_FW2.
>
> Then add an outbound NAT rule to the management VLAN interface, use FW1_FW2 for the destination, translation = interface address (default), save.

This is helpful for me too, but:
Restrict the source address to "Wireguard (Group) net".

Without that restriction I had the issue that a zabbix proxy was no longer reachable on the secondary opnsense. The zabbix proxy rejected connections from the zabbix server because they appeared to come from the primary opnsense.

[Output shown here for diagnostic purposes. There is no general need for manual system intervention.]

#8

26.1, 26,4 Series / Re: Intel ucode Plugin vs Pack...

Last post by Patrick M. Hausen - Today at 12:03:23 PM

It appears that it's the x86info utility (also installed by the plugin) that reports itself as deprecated, not the (whole) plugin.

Correct. People also tend to overlook the message below that text box:

Output shown here for diagnostic purposes. There is no general need for manual system intervention.

#9

26.1, 26,4 Series / Re: Intel ucode Plugin vs Pack...

Last post by dseven - Today at 11:53:27 AM

IIUC...

The package (cpu-microcode-intel) gets installed by the plugin (os-cpu-microcode-intel) - no plugin, no package!

It appears that it's the x86info utility (also installed by the plugin) that reports itself as deprecated, not the (whole) plugin.

#10

German - Deutsch / Re: Unbound unter OpenVPN

Last post by Patrick M. Hausen - Today at 11:45:00 AM

Kernfgrage : Auf welchem Interface laufen die Unbound-Anfragen für OpenVPN - meine Vermutung ist, dass das WAN hierfür verwendet wird.

Das OpenVPN-Interface, naheliegenderweise. Das hat doch eine IP-Adresse im Infrastruktur-Modus.