Messages

Tatsächlich habe ich per Google den Link zur Doku gesucht, da ich den nicht als Lesezeichen gespeichert habe - habe ich jetzt nachgeholt.
Diese Googlesuche hat mich auf die falsche Fährte geführt.
Ansonsten bin ich generell ein grosser Fan zunächst das Handbuch zu lesen.

Das ist peinlich!
Vielen Dank für die Links.
Offensichtlich hat mich die Googlesuche immer auf die alte Dokumentation geführt. Auch die Suche mit "How to..." hatte zu keinen treffenden und hilfreichen Ergebnissen geführt. Auch ChatGPT referrenzierte "alte" Konfigurationseinstellungen.

Vielen Dank für die Mühe

Hallo Forum,
da ich eine Verbindung zu einem IPsec Gateway aufbauen möchte, beschäftige ich mich mit IPsec.
Derzeit nutze ich OPNsense in der Version 25.7.3_7.
Ich finde keine Dokumentation mit der neuen Konfigurationsoberfläche. Kann mir jemand helfen und mir einen Hinweis geben, wo ich die finden kann?

Vielen Dank

ChatGPT helped me in the following way:

### ✅ **Kea DHCPv6 CSV Import – Expected Format**

While ISC Kea's web UI supports CSV imports, **the format must align exactly** with what the backend expects. For **DHCPv6 reservations**, the expected fields usually include:

```
duid,ip-addresses,hostname,hw-address,subnet-id
```

However, **`hw-address` is usually not used for DHCPv6**, and **you should focus on `duid` instead**.

---

### ⚠️ Clarifying the fields you mentioned:

| Your Field    | Expected? | Comments                                                                                             |
| ------------- | --------- | ---------------------------------------------------------------------------------------------------- |
| `subnet`      | ❌         | Not recognized as a valid column name – should be `subnet-id` (an **integer** ID, not subnet string) |
| `ipv6`        | ❌         | Should be `ip-addresses` (and must be a list, i.e., `["2001:db8::100"]`)                             |
| `hostname`    | ✅         | Accepted                                                                                             |
| `description` | ❌         | Not supported in CSV import – ignored or causes error                                                |

---

### ✅ **Minimal working example (DHCPv6)**

Try a CSV file like this:

```csv
duid,ip-addresses,hostname,subnet-id
00:03:00:01:aa:bb:cc:dd:ee:ff,"[\"2001:db8::100\"]",example-host,1
```

* **`duid`**: The DUID of the client (use actual format matching your client config, e.g. `00:01:00:01:...`)
* **`ip-addresses`**: Must be a **JSON array as a string**, even for one IP.
* **`subnet-id`**: This must match the `id` field of your configured DHCPv6 subnet (not the subnet address).
* **Headers are required.**

---

### 🔍 How to find `subnet-id`

In your Kea DHCPv6 config (usually in `kea-dhcp6.conf`), each subnet has a field:

```json
"subnet6": [
  {
    "id": 1,
    "subnet": "2001:db8::/64",
    ...
  }
]
```

Use the number from `"id": ...` as `subnet-id` in your CSV.

---

### 🧪 Troubleshooting the errors

| Error                             | Likely Cause                                                                             |
| --------------------------------- | ---------------------------------------------------------------------------------------- |
| `Duplicate entry exists`          | Same `duid` or `ip-addresses` already in config (check even old config fragments)        |
| `A value is required`             | One of the required fields (`duid`, `ip-addresses`, `subnet-id`) is missing or malformed |
| `Address not in specified subnet` | IP address does not fall within the subnet tied to `subnet-id`                           |

---

### ✅ Recommendations

1. Start with **one simple reservation** and verify import.
2. Use a **minimal field set**: `duid`, `ip-addresses`, `hostname`, `subnet-id`.
3. Validate `duid` format and ensure `subnet-id` matches exactly what Kea expects.
4. Check the Kea logs (`/var/log/kea.log` or wherever your system logs them) for detailed import messages.

---

I'm a typical OPNsense user managing a home network and a small business environment. As a non-expert network engineer, I'm genuinely grateful for how reliably and efficiently OPNsense runs. Much of this is thanks to the outstanding work of the OPNsense developers and the helpful community here in the forum.

After the deprecation of ISC DHCP, I migrated to Kea. The transition was seamless, and my setup has continued to work flawlessly ever since.

Here's what my configuration looks like:
- **Clients** receive **IPv4 addresses via Kea DHCP**.
- **IPv6 addresses** are assigned via **SLAAC** using router advertisements.
- **DNS** is handled through **AdGuardHome** (for filtering), and **Unbound** for DNS-over-TLS.

Important clients in my LAN/VLANs have **static leases** via Kea, and I use those for internal DNS assignments. Since my network doesn't undergo significant dynamic changes, I don't currently require DDNS.

That said, I'm following this discussion with interest — not because I'm facing any issues now, but because I'm thinking ahead. The deprecation of ISC DHCP seems to have triggered a broader strategic discussion about the default DHCP system in OPNsense.

My concern is whether Kea will continue to be supported and actively integrated into OPNsense, or whether it will fall to a lower priority in favor of dnsmasq — even though dnsmasq itself hasn't seen much development since 2024 and may not be as future-proof.

I'm very happy with my current setup and could certainly continue using it as-is. But I wonder: why not make Kea more accessible for small environments by focusing the GUI integration on the most common use cases? For example, DDNS support could be added via a simple checkbox to enable the Kea D2 module. The user would just enter a BIND server address and a TSIG key name — no full mapping of all Kea capabilities would be needed in the GUI.

I don't know how much development effort this would take — and that may be the limiting factor — but from a user's perspective, such a step would make Kea much more approachable and clearly position it as the forward-looking standard in OPNsense.

Kannst du damit was anfangen?

Auch wenn ich nicht gemeint bin und Patrick der sicherlich sehr viel bessere Helfer ist, möchte ich mich doch in einer Interpretation versuchen, auch um mitzulernen:
Da Adguard scheinbar funktioniert, aber in den tcdump Mitschnitt ein nxdomain auftaucht, kann das Problem in unbound und seiner Konfiguration liegen

FritzBox: wie hasst du die den angeschlossen, hinter der OPNSense als Client oder davor ?

Ah ne in Unraid ist alles okay, da hab ich keine Sorge.

Die Fritzbox ist als Client hinter der OPNsense.

Nochmal in aller Deutlichkeit: Wenn ich Unbound und Adguard deaktiviere, dann geht es sofort mit der VoIP Registrierung

In meiner Konfiguration habe ich bei DNS Server v4 vom Internetanbieter... eingestellt.

Damit ist die OPNsense der DNS Server: AdGuard -> Unbound. Abhängig von deiner Firewalleinstellung verhindert der "fremde" DNS Server bei aktivem AdGuard und Unbound eine Verbindung, weil die OPNsense diese blockiert
Schaltest Du Adguard und Unbound aus, wird der Zugriff auf den "fremden" DNS Server nicht mehr blockiert.

hast du denn auch adguard und unbound am laufen?

Ja, habe ich.
Allerdings habe ich die FB in einem separaten VLAN, da die Stabilität der SIP Verbindungen durch das "Geschnatter" aller im Netz befindlichen Geräte empfindlich gestört war. Erst mit der Separierung der FritzBox gab es keine Unterbrechungen mehr bei der Verbindung.
WLAN realisiere ich durch separate AP, da auch die eingeschränkte Funktionalität der FB nicht mehr reichte um Netze zu separieren. Gleiches gilt für SmartHome.

FritzBox: wie hasst du die den angeschlossen, hinter der OPNSense als Client oder davor ?

Ah ne in Unraid ist alles okay, da hab ich keine Sorge.

Die Fritzbox ist als Client hinter der OPNsense.

Nochmal in aller Deutlichkeit: Wenn ich Unbound und Adguard deaktiviere, dann geht es sofort mit der VoIP Registrierung

In meiner Konfiguration habe ich bei DNS Server v4 vom Internetanbieter... eingestellt.

Falls noch jemand Interesse hat: Ich habe für mich eine Lösung gefunden ohne WSUS Server meinen beiden Windows Servern nur Updates zu erlauben, aber weiteren Internetzugang zu unterbinden und möchte dies hier vorstellen, gerne auch Verbesserungsvorschläge.

Microsoft Windows Update über ASN freigeben

Microsoft verwendet mehrere ASNs für Windows Update und Azure-Dienste. Die wichtigsten sind:
AS8075  → Microsoft Corporation (Windows Update, Office, Azure)
AS12076 → Microsoft Azure (Global)
Diese ASNs enthalten immer die aktuellen Windows Update IPs

Da ich IPv4 und IPv6 nutze, identifiziere ich die Windows Rechner über die MAC Adresse der LAN Schnittstelle, die sich nicht ändert (ausser man erzwingt dies). Dies sollte für alle genutzten Netzwerkschnittstellen erfolgen, will man die Rechner identifizieren. Bei Verbindungen über WLAN besteht die Besonderheit, dass es dort zum Schutz der Privatsphäre zu Änderungen der MAC Adresse kommen kann. Dies sollte im Heimnetz deaktiviert werden. Für mich spielt das keine Rolle, da meine Windows Server über LAN mit dem internen Netz verbunden sind. 



OPNsense Alias für BGP-ASN erstellen

Gehe zu Firewall → Aliases → Hinzufügen (+)
Name: Windows_Update_ASN
Typ: BGP ASN
AS-Nummern: 8075 12076
Kategorie: Windows Clients
Beschreibung: Windows Update ASN
Speichern & Übernehmen


OPNsense Alias für Windows MAC Adressen erstellen

Gehe zu Firewall → Aliases → Hinzufügen (+)
Name: Windows_Client_MAC
Typ: MAC Adressen
MAC Adresse: 11:22:33:44:55:66
Kategorie: Windows Clients
Beschreibung: Windows Client MAC Adressen
Speichern & Übernehmen


Firewall-Regeln für den Client

Jetzt Client nur Verbindungen zu diesen ASNs erlauben:
Regel 1: Windows Update zulassen
Gehe zu: Firewall → Regeln → LAN (bzw. Schnittstelle in der sich die Windows Rechner befinden)
Aktion: Erlauben
Protokoll: TCP/UDP
Quelle: Alias (Alias MAC Adresse Windows Client)
Ziel: Alias Windows_Update_ASN
Speichern & Übernehmen

Regel 2: Alle anderen Verbindungen der Windows Clients blockieren
Aktion: Blockieren
Quelle: Alias (Alias MAC Adresse Windows Client)
Ziel: any
Speichern & Übernehmen`

Welche Gründe gibt es konkret, weshalb der Weg mit Kea nicht mehr weiterverfolgt wird?
Ist Kea ein totes Gleis und ich sollte mir langsam Gedanken zu  einer Umstellung der Dienste machen?
Im Moment bin ich bei einem einfachen Setup sehr zufrieden mit Kea, stabil und schnell.
Wie funktioniert eine Dienstekombination mit DNSMasq, Unbound und AdguardHome?

Viele Grüsse
Bernd

I would also like to thank you. Not only for the smooth update to 25.1.2 but also for all the previous work in the forum. Thank you Franco, but also all the other members in the forum: Patrick M. Hausen, cookiemonster, meyergru, newsense, viragomann, Monviech (Cedrik) and all the others I have forgotten.

I have the same problem
Is this possibly the answer to the problem?

https://community.emergingthreats.net/t/etpro-telemetry-edition/2355

"For sensors opting-in to sending Proofpoint/ET telemetry so they can receive ETPRO telemetry edition those sensors must have sent event telemetry back to Proofpoint/ET within the last 5 days.

Sensors may go dormant during that period (no heartbeat sent in the last day) and still receive ETPRO Telemetry Edition, but if no events are received for 5 days the Telemetry Edition rule delivery will be disabled and that sensor will simply receive that day's ET Open rules.

That disabling will transition back to active delivery upon resumption of heartbeat and telemetry delivery back to Proofpoint/ET.

Sensors are reviewed as to state every 24 hours."

In my case it helped to generate a new SSH key.
There was no need to turn off the firewall.

Does resetting the SSH key help?

ssh-keygen -R <IP-Adresse/Name>