Messages

die Ansicht bereitet mir, aufgrund der Logik dahinter weitaus weniger Kopfschmerzen als die art und weise (sehr strict) die Kea verfolgt.
Ich denke ich muss mir mal in ruhe anlesen wie genau KEAs Logik funktioniert (denn am ende des Tages geht es nur darum).

Wie gesagt was ich nicht ganz verstehe:

Im Endeffekt ist das alles ein Routing Thema,
Wenn man irgendein interface als MGMT interface nutzt welches mit einem VLAN Interface kommuniziert muss man dafür sorgen das beide sich "sehen" also kommunizieren können.

Wo ich mit meiner Menschlichen Logik nicht hinterherkomme ist das genannte Szenario.

MGMT (physical) interface und ein VLAN Interface kommunizieren bereits, die Clients des VLAN Interface bekommen per DHCP ihr lease.

Aber und obwohl (mehrfach kontrolliert) jedes Interface sein eigenes oder das der OPNSense als Gateway definiert hat, können trotz entsprechenden Regeln, ein anderes VLAN Interface welches für den Unifi-Server genutzt wird, nicht kommunizieren.

Der Weg einfach erklärt ist hier in meinem Verständnis:

WIFI MGMT teilt dem UNIFI-Controller in VLAN X mit das in VLAN Y ein UFO hängt.


Das funktionierte bisher mit ISC auch, soweit ich das aber nachvollziehen kann war ISC nicht so strikt und hat gern mit Broadcast abfragen gearbeitet, welche auch wiederum bösartige Ausnutzung ermöglicht.

KEA ist dort strikter und kommuniziert nur wenn man mitteilt wie der weg funktioniert.

Demnach muss man den Rout(ing)enplaner bereits vorab eingestellt haben, sonst schreit KEA halt: " ey wat du wolle, ich nix verstehe!".


Sollte meine Logik hier hinken o.ä. immer her mit Konstruktiver Kritik.

Oh das ist zum Mäusemelken....

Was ich hin bekomme:
Firewall von alt zu new --> check
isc -> kea check

Alles funktioniert bis auf der AP. Leckofatzi!

Lustigerweise habe ich alles ex und wieder importiert, danach kommt etwas lustiges zustande:

Ich bekomme an WIFI Clients ein lease -> yiaaay
Aber im unifi-control server und via ping keine Verbindung zum UFO U6+

Setze ich alles per snapshot zurück funktioniert alles wie gewohnt.

Der unterschied:

ISC einmal WIFIMGMT auf opt 1 GW: 192.168.12.252/29 AP hat die IP 192.168.12.2
ISC WIFI vlan0.20 GW: 192.168.13.252/24 -> da bekommen die clients dann wifi

In Kea alles händisch eingetragen, rein ne va plus!

Nach Recherche brauche ich wohl die Möglichkeit die option 43 zu vergeben weil der AP sonst blind ist.
Ich hab es per Unbound DNS override probiert, nope will einfach nicht.

Ich gebs für heute auf... Ratschläge / Erklärung sehr willkommen.

Hab ich auch:
General Settings -> Interfaces alle bisherigen drin.

Ja ich vergas zu erwähnen: natürlich hab ich die Subnetze erst in KEA angelegt :)

Moin zusammen,
also es ist völlig egal was ich anstelle ich bekomme es nicht gebacken.

Zur Migration von ISC -> KEA (aktuell nur v4) habe ich das Tool aus dem Forum hier genommen (https://github.com/EasyG0ing1/Migration).

Das funktioniert soweit auch.

Soweit so gut.

Nun deaktiviere ich jegliches DHCP auf ISC (vorher dafür gesorgt das ich mich nicht aussperre ;)) und aktivere KEA.

Das läuft soweit teilweise, als dass ich auf konfigurierten VLANs nur noch eine APIPA bekomme. Lediglich mein LAN welches ich statisch konfigiert habe leistet noch seine Arbeit.


Wenn ich nun noch den EX- Import für die neuen FW Regeln mache geht garnichts mehr.


Wo ist mein Denkfehler bzw. was muss ich tun um das mit den aktuellen Möglichkeiten wieder ans fliegen zu bekommen?

If you're using clicks, you're not a modern OPs.
Its not a Windows Machine where you Click anything and hopefully not build a SecurityFlaw....

If you wan't to administer OPNSense over a modern Way (like API) I suggest to read the Manual.
There's a way to use the API for that (that's how I do it with versioning and a Git repo in my local Network only for this task).
It Takes 2-3 Minutes and voila a new VLAN is there.

Here's an Example on how to do it:

Code Select Expand

curl -X POST "https://OPNSENSE-IP/api/interfaces/vlan/addVlan" \
  -H "Content-Type: application/json" \
  -u "APIKEY:APISECRET" \
  -d '{
        "vlan": {
            "enabled": "1",
            "tag": "30",
            "description": "LAN_Prod",
            "if": "igb0",
            "priority": "0"
        }
      }'

Its a simple curl Post Call with a json file:

| Field         | Description                                 |
| ------------- | ------------------------------------------- |
| `enabled`     | 1 = enable VLAN                             |
| `tag`         | The VLAN ID (e.g., 30)                      |
| `description` | Description visible in GUI                  |
| `if`          | Parent physical NIC (e.g., igb0, igb1, em0) |
| `priority`    | Optional (0–7)                              |

To verify:

Code Select Expand

curl -X GET "https://OPNSENSE-IP/api/interfaces/vlan/searchVlan" \
  -u "APIKEY:APISECRET"

What exactly is your problem? Your statement doesn't make sense.

Hell Yeah, it works.
But I didn't use Interface Rules instead of them I have a floating rule for have a clean ruleset on my interfaces.

I see many Events on WAN / LAN but what I miss is a description of the Event.

@Q-Feeds what do you mean, is there a way to get more Information out of that?

Which Options do I have to play with (if possible) the API of this plug?
For deeper insights, which logs can I check?
How can I see these events in a SIEM/XDR like Sentinel or WAZUH?

And one thing: I don't know why but login with UserName on Q-Feeds Site isn't possible anymore.
Also I didn't get any email when ordering a new password.... ;(

@Seimus which block rules do you mean exactly? I have different rules (floating and because of micro segmentation of my vlans some special rules depending on my needs).
So for it only Interesting for LAN / WLAN / WAN.

But wait I need to check the Docs first, as far as I know its already in the OPNSense Docs....

ah now I see what you mean .... I let you know if it changed something after I set the rule (I think its easier to create a floating rule in my case ) but thank you, after a day of coding my heady bangs too hard and I oversee things ;)

Ok I installed it, made the registration, add the api thing and nothing happens, I didn't see anything under Events.
Under Feeds I see two entries:
Malicious IP addresses
Malicious domain names
domains
2025-10-26T00:00:00Z
2025-10-26T00:00:007
2025-10-27T00:55:277
2025-10-27700:55:277

everything with a checkmark.

So my question is, what exactly should I expect?

Normally I use crowdsec (which is definitively extremely a money made machine....)

sounds very nice, I wrote a message to test it in the entire thread ;)

I would be very happy to test it.
Only an IT Consultant with some gained Security Experience ;)

@EricPerl
curios, in my configuration it works as described.
The Block Rule RFC1918     *    Block LANDMZ to internal without anything else block all traffic in my entire lan, how I test it?

ping 192.168.11.1    --> no ping allowed
traceroute 192.168.11.1 --> no tracerout possible

also:

nmap -p 22,80,443 192.168.11.1 --> says everything is filtered
nc -zv 192.168.11.1 22 --> says for all the ports its unreachable

no web interface is useable from one of the dmz hosts.

On OpNSense:

Firewall > Log Files > Live View

Filter:

Interface: LANDMZ

Action: Block

Destination: RFC1918 IPs

so why should it not working?

@Patrick M. Hausen,
oh my god.... it works...
you are my hero of the day ;)
Thank you!

Hey together,

I configured a DMZ in my vlan.

everything works except the firewall rule for DNS which should be the Interface Address.

I Use Unbound for everything.

I set an ACL in Outbound for it.
My Firewall Rules are:

Protocol   Source   Port   Destination   Port   Gateway   Schedule      Description
IPv4 TCP/UDP   LANDMZ net   53 (DNS)   dmz_ns    53 (DNS)   *   *      Forward DNS       
        IPv4 ICMP   LANDMZ net   *   *   *   *   *      Allow ICMP to OPNsense       
        IPv4+6 *   LANDMZ net   *   RFC1918    *   *   *      Block LANDMZ to internal       
        IPv4+6 *   LANDMZ net   *   ! RFC1918    *   *   *      Allow access to Internet and block access to all local networks       
        IPv4 *   LANDMZ net   *   FLUX_IPs    *   *   *      Allow to admin PC only       
        IPv4 *   LANDMZ net   *   *   *   *   *      Block all other

Why can't the dmz reach the DNS?
I'm confused about that.

Of course:

Code Select Expand

# DO NOT EDIT THIS FILE -- OPNsense auto-generated file


# Global Options
{
log {
output net unixgram//var/run/caddy/log.sock {
}
format json {
time_format rfc3339
}
}

servers {
protocols h1 h2 h3
trusted_proxies static 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}

dynamic_dns {
provider cloudflare
domains {
zerot3ch.de *
zerot3ch.de remotely
}
ip_source interface igc0
update_only
}

email xxx@gmail.com
grace_period 10s
import /usr/local/etc/caddy/caddy.d/*.global
}

# Reverse Proxy Configuration


*.zerot3ch.de {
log {
output file /var/log/caddy/access/bb35164d-3b13-4c5c-a47e-6499b75c76da.log {
roll_keep_for 10d
}
}
tls {
issuer acme {
dns cloudflare
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_zerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_zerot3chde {
abort
}
}

remotely.zerot3ch.de {
log {
output file /var/log/caddy/access/2b8651a0-b5db-41f6-9d3b-9a8f1109f3e1.log {
roll_keep_for 10d
}
}

@258c701d-7862-4552-b894-d961cdbab7e4_remotelyzerot3chde {
not client_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
}
handle @258c701d-7862-4552-b894-d961cdbab7e4_remotelyzerot3chde {
abort
}

handle {
reverse_proxy 192.168.11.60:5000 {
transport http {
}
}
}
}

This is the only reverse proxy entry which works.

Curiously if I remove the Access List from other entries than the remotely entry, it works.

Can someone explain why?

I use this described at https://docs.opnsense.org/manual/how-tos/caddy.html#restrict-access-to-internal-ips

Options Values
Access List Name: private_ipv4
Client IP Addresses: 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
Description: Allow access from private IPv4 ranges