Messages

As far as i understand it correctly, not all tunables are for every hardware right?
I have many tunables configured, some on the hard way (something broke needed a restore to backup settings).
So my question is: How can i proof that these tunables are working with my Hardware?

ich drösel das mal verständlich auf.
IPs habe ich mit absicht mal weg gelassen.

KEA läuft nun, hat ein wenig gedauert bis ich die Doku verinnerlicht hatte und verstanden wie ich das in OPNSense umsetze.
Testen von Kea auf einer FreeBSD VM war erst mal einfacher (Übung macht den Meister und so ;) ).

hier meine Netzwerktopologie:

                                                           ┌─────────────────────┐
                                                           │   INTERNET (WAN)                                                   │
                                                           │   igc0 (Public IP)                                                         │
                                                           └──────────┬──────────┘
                                                                                                          │
                                                        ┌───────────┼─────────-┐
                                                         │                                                                                          │
                       ┌───────▼────────┐                   ┌───────▼────────┐
                      │   GeoIP Block                                          │                   │  Threat Feeds  │
                      │  (133 countries                                        │                   │ (FIREHOL, etc) │
                      │   263k IPs)                                                │                   └───────┬────────┘
                     └───────┬────────┘                                                       │
                                                       │                                                                                             │
                                                       └────────────┬─────────┘
                                                                                                              │
                                                                 ┌──────────▼──────────┐
                                                                 │   FIREWALL RULES                                                  │
                                                                 │  • SYN Proxy                                                                │
                                                                 │  • Rate Limiting                                                          │
                                                                  │  • State Tracking                                                        │
                                                                  └──────────┬──────────┘
                                                                                                                 │
                                                                  ┌──────────▼──────────┐
                                                                  │   SURICATA IPS                                                           │
                                                                  │  • Netmap (IPS)                                                           │
                                                                  │  • 24,591 rules                                                               │
                                                                  │  • Hyperscan                                                                 │
                                                                  └──────────┬──────────┘
                                                                                                                 │
        ┌──────────────────────────────┼──────────────────────────┐
        │                                                                                                                               │                                                                                                               │
        │                                                                                                                               │                                                                                                               │
┌───────▼────────┐          ┌──────────▼──────────┐                               ┌─────────▼──────┐
│  LAN (LANPROD)                                │          │   VALHALLA (opt3)                                                    │                               │  WireGuard VPNs                                │
│  vlan0.11                                                   │          │   Media/IoT VLAN                                                     │                               │  WG0/WG2/WG3_TOR                     │
│  • Workstations                                     │          │   • LibreELEC                                                               │                               │  • Remote Access                                 │
│  • Servers                                                │          │   • Smart Devices                                                        │                               │  • Tor Routing                                          │
│  • Management                                   │          │   • Squid Proxy                                                              │                               └────────────────┘
└────────────────┘          └─────────────────────┘
                                  │                                                                                              │
                                  │                                                                                              │
┌───────▼────────┐          ┌──────────▼──┐
│  LANPROD (opt6)                                │          │   IOT_WIFI (opt7)                      │
│  • Production                                          │          │   • IoT Devices                            │
│  • Docker                                                  │          │   • Internet Only                        │
│  • Caddy                                                  │          └─────────────┘
└────────────────┘
                                 │
┌───────▼────────┐          ┌──────────────┐
│  LANDMZ (opt9)                                   │          │  GUESTNET (opt4)                       │
│  • DMZ Services                                     │          │  • Guest WiFi                                  │
│  • Public Apps                                        │          │  • Isolated                                        │
└────────────────┘          └──────────────┘
                                 │
┌───────▼────────┐          ┌─────────┐
│ TOR_NET (opt10)                                 │          │  LANTEST (opt8)     │
│  • Tor Proxy                                             │          │  • Testing                    │
│  • Transparent                                        │          └─────────┘
└────────────────┘

Key Services & Servers:

Interface   Name        Type           VLAN   Network           Purpose
igc0           WAN        Physical           -   Public IP   Internet gateway
vlan0.11   LAN         VLAN           11   192.168.x.0/24   Primary LAN
igc2           WIFI        Physical           -   -           WiFi Access Points
opt1           WIFI (mgmt)  VLAN           -   -           AP Management
LANMGMT           -        VLAN           -   -   Management VLAN
WIFIMGMT   -        VLAN           -   -   WiFi Management


Network Segmentation Strategy:

Service                           Location   Interface   IP/Alias   Purpose
UniFi Controller                Server           LAN           UNI_SRV           WiFi management
U6 Access Point                   Hardware   WIFI           U6_AP           WiFi AP


Network Segmentation Strategy:

Zone           Trust Level   Interfaces   Outbound Access         Inbound Access
Management   HIGHEST           LAN, LANMGMT   Full                 SSH from admin IPs only
Internal   MEDIUM           VALHALLA (opt3)   Filtered via Squid    LAN only


Die Ufos hängen im WifiMgmt Netz, sie beziehen Ihre IP von dort.
Alle VLANs im WIFI werden an der OpnSense vergeben.

Heisst jedes WIFI Netz bekommt eigene Settings verpasst.

Der Management-Traffic (Provisionierung, SSH, SNMP der APs) läuft isoliert über WIFIMGMT. Ein Angreifer, der ein User-WLAN knackt, sieht die APs selbst also nicht einmal.

Das Tagging passiert direkt am AP und am Switch: Der UniFi Controller pushed die SSIDs mitsamt ihren VLAN-Tags (z.B. Guest, IoT, Valhalla) auf die APs. Der Switchport, an dem das Ufo hängt, läuft als Trunk (Native VLAN = WIFIMGMT / Tagged VLANs = der Rest).

Der DHCP/Gateway-Endpunkt ist die OPNsense. Da Kea nun läuft, kannt ich jedem Interface/VLAN völlig autarke Scopes, DNS-Server (z.B. Unbound mit DoT) und Lease-Times zuweisen.

Alles bis auf Administrativen zugriff für bestimmte Accounts ist Isoliert vom restlichen Netzwerk.

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!