Topics

Hi all,

I know this is a very minor issue compared to what functionality the product offers.

However, just having upgraded from 24.7 to 25.1, the font has changed and thus the readability of the web user interface. Compared to 24.7, now with 25.1 the font looks "condensed" in a way that the height/width ratio has changed considerably, making reading information in the UI harder for me.

When I use some browser developer tools I can see that it's due to the font family being declared as "SourceSansProRegular" with highest priority. If I remove that setting dynamically with the browser's dev tools, the font immediately returns to being clearly readable.

Is there any way to configure this within OPNsense itself or do I have to install browser extensions to change that?

BTW: I have checked with both, Firefox and Chrome (most recent versions) on a Debian GNU/Linux box as well as with Chrome Edge on Windows.

Hi all,

after some outages of my VDSL provider, I decided to go for a 4G/LTE backup.

I chose the Netgear LM1200 in bridge mode with a O2 prepaid SIM. Interface in OPNsense is called WAN2. My main connection is via PPPoE and a Vigor 167. Interface is called WAN.

With my (main) WAN I have a dual IP stack, so there exists a gateway for IPv4 and one for IPv6. As I want to set up WAN2 as failover for WAN, I have now added a monitor IP 8.8.8.8 to my WAN IPv4 gateway and a monitor IP 2001:4860:4860::8888 to my WAN IPv6 gateway (also I have unticked the "gateway is always up" checkboxes and ticked the "allow dynamic gateway switching" checkbox).

Also I have created two gateway groups, one for IPv4 and one for IPv6, each containing the WAN IPv4 / WAN2 IPv4 and WAN IPv6 / WAN2 IPv6 respectively (priorities have been set to 254 and 255 as well as chosen as Tier 1 and Tier 2 in the groups).

I can then see two dpinger services running (one for WAN IPv4 monitor IP and one for WAN IPv6 monitor IP).

And now my issue:

This only works as long as I do not enable IPv6 on the 4G/LTE modem. If I configure PDP mode to IPv4v6 (instead of just IPv4), the WAN2 interface also gets assigned an IPv6 address and an IPv6 gateway (which otherwise is empty), and as soon as this happens, the dpinger for the monitor IP of WAN IPv6 goes red, thus marking the WAN IPv6 gateway as down.

I can ping the WAN IPv6 gateway from clients in the LAN as well as from the OPNsense itself, so I wonder why dpinger of the monitor IP of WAN IPv6 goes down as soon as WAN2 also gets IPv6 assigned.

What may - or may not - be of interest is the fact how I get the IP addresses assigned:

WAN IPv4: public Deutsche Telekom IPv4
WAN IPv6: fe80::%pppoe0 link local address, also gateway is fe80:: link local

WAN2 IPv4: private 10.0.0.0/8 IPv4 by O2
WAN2 IPv6: public 2a02::/128 IPv6

I'd be grateful if anyone can see what is going on and what I'm missing in order to get Dual WAN Dual IP Stack with two pairs of two gateways up on green for normal operation. Happy to provide more information or answer questions if necessary.

Greetings,
Stefan

Hi,

since updating from 23.7 to 23.7.1, something regarding the ntpd seems to have changed. I now get the ntpd.log flooded with

Code Select Expand


...
Soliciting pool server 213.209.109.44
Soliciting pool server 2a01:238:4204:fc00:4b47:ee22:4277:df4e
Soliciting pool server 46.4.54.78
Soliciting pool server 2a01:238:4200:a000:8f15:af83:9bee:b97d
Soliciting pool server 185.232.69.65
Soliciting pool server 193.175.73.20
Soliciting pool server 162.159.200.123
Soliciting pool server 2a01:238:43f2:8900:dd04:e3a0:ee11:a73d
Soliciting pool server 162.159.200.123
Soliciting pool server 144.76.159.151
Soliciting pool server 159.69.69.50
Soliciting pool server 80.151.186.5
Soliciting pool server 85.25.148.4
Soliciting pool server 131.188.3.220
Soliciting pool server 195.201.20.16
Soliciting pool server 173.249.33.207
Soliciting pool server 213.209.109.45
Soliciting pool server 192.171.1.150
Soliciting pool server 87.106.180.117
...


for the default

Code Select Expand


# Upstream Servers
pool 0.opnsense.pool.ntp.org maxpoll 9 prefer
pool 1.opnsense.pool.ntp.org maxpoll 9
pool 2.opnsense.pool.ntp.org maxpoll 9
pool 3.opnsense.pool.ntp.org maxpoll 9


configuration.

Previously, ntpd was identifying itself as

Code Select Expand


ntpd 4.2.8p17@1.4004-o Fri Jul 28 02:13:36 UTC 2023


Now it is

Code Select Expand


ntpd 4.2.8p17@1.4004-o Tue Aug  8 02:15:10 UTC 2023


Any ideas?

EDIT: I reverted back to 23.7 and the problem vanished again, so it's definitely related to the 23.7.1 update.

Hi all, I did a single configuration change, adding a Virtual IPv6 address to my LAN to create an ULA, and the OPNsense did not boot anymore (tried with 23.1_6 and 23.1.1_2).

The configuration diff is as simple as

Code Select Expand


2010,2011c2025,2039
<   <virtualip>
<     <vip/>
---
>   <virtualip version="1.0.0">
>     <vip uuid="fa820ff4-41b4-4c9a-8595-8373a45fef7d">
>       <interface>lan</interface>
>       <mode>ipalias</mode>
>       <subnet>fd80:0192:0168:0001:2a1:ecff:fe68:f1c0</subnet>
>       <subnet_bits>64</subnet_bits>
>       <gateway/>
>       <noexpand>0</noexpand>
>       <nobind>0</nobind>
>       <password/>
>       <vhid/>
>       <advbase>1</advbase>
>       <advskew>0</advskew>
>       <descr>ULA LAN</descr>
>     </vip>


This results in the Enter full pathname of shell or RETURN for /bin/sh at boot directly after Setting up routes...done. and before Setting up DHCPv4 and Setting up DHCPv6. This was reproducible every time and was not a one-time timing hickup.

Luckily I have virtualized the OPNsense on Proxmox VE, so I just reverted to the last snapshot.

I then learnt that I used a stupid address for ULA and changed it to a randomly generated one and now OPNsense boots again. The only change in the diff is really the <subnet>...</subnet> of the <virtualip>.

Even if I used a stupid virtual IPv6 address, I think, OPNsense should not refuse to boot?

Hi all,

I have a virtual OPNsense running on Proxmox VE connected to a Draytek Vigor 167 on a VDSL100 from Deutsche Telekom running with dual stack.

Every few days there's a disconnect and sometimes afterwards IPv6 is dysfunctional (DHCPv6 is not runnig). With 22.7 I could use the DHCPv6 Reload button in Interfaces -> Overview -> WAN, but now with 23.1_6 this does not work for my any more. Even Reload PPPoE does not work reliably and I have to reboot everything.

My configuration:

WAN:
IPv4: PPPoE
IPv6: DHCPv6
Request only an IPv6 prefix
Prefix delegation size 56
Send IPv6 prefix hint
Use IPv4 connectivity

LAN:
IPv4: Static IP
IPv6: Track interface (WAN)

What kind of logs should I provide to further track this down? Pressing a "DHCPv6 Reload" button every now and then was "ok", but the situation right now is really starting to get a nuisance, I have to say. :-(

Edit: To clarify, my last sentence was not meant as a complaint against the developers. I understand how hard it is to cater for all scenarios, especially without the exact setup to reproduce the issues. It was rather meant to express how desperate I am and that I am willing to debug it in order to come to a solution once and for all.

I just upgrade to 23.1 from 22.7.11 via 22.7.11_1. Everything in the process seems to have worked. However now I wanted to check for further patch level upgrades and when doing so, I got the following:

Code Select Expand


***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 23.1 at Tue Jan 31 17:36:05 CET 2023
Fetching changelog information, please wait... done
Updating OPNsense repository catalogue...
pkg: sqlite error while executing SELECT count(name) FROM sqlite_master WHERE type='table' AND name='repodata'; in file pkgdb.c:2357: database is locked
pkg: Repository OPNsense load error: unable to query db: Resource temporarily unavailable
Fetching meta.conf: . done
Fetching packagesite.pkg: .......... done
pkg: sqlite error while executing CREATE TABLE packages (id INTEGER PRIMARY KEY,origin TEXT,name TEXT NOT NULL,version TEXT NOT NULL,comment TEXT NOT NULL,desc TEXT NOT NULL,osversion TEXT,arch TEXT NOT NULL,maintainer TEXT NOT NULL,www TEXT,prefix TEXT NOT NULL,pkgsize INTEGER NOT NULL,flatsize INTEGER NOT NULL,licenselogic INTEGER NOT NULL,cksum TEXT NOT NULL,path TEXT NOT NULL,pkg_format_version INTEGER,manifestdigest TEXT NULL,olddigest TEXT NULL,dep_formula TEXT NULL,vital INTEGER NOT NULL DEFAULT 0);CREATE TABLE deps (origin TEXT,name TEXT,version TEXT,package_id INTEGER REFERENCES packages(id)  ON DELETE CASCADE ON UPDATE CASCADE,UNIQUE(package_id, name));CREATE TABLE categories (id INTEGER PRIMARY KEY, name TEXT NOT NULL UNIQUE );CREATE TABLE pkg_categories (package_id INTEGER REFERENCES packages(id)  ON DELETE CASCADE ON UPDATE CASCADE,category_id INTEGER REFERENCES categories(id)  ON DELETE RESTRICT ON UPDATE RESTRICT,UNIQUE(package_id, category_id));CREATE TABLE licenses (id INTEGER PRIMARY KEY,name TEXT NOT NULL UNIQUE);CREATE TABLE pkg_licenses (package_id INTEGER REFERENCES packages(id)  ON DELETE CASCADE ON UPDATE CASCADE,license_id INTEGER REFERENCES licenses(id)  ON DELETE RESTRICT ON UPDATE RESTRICT,UNIQUE(package_id, license_id));CREATE TABLE option (option_id INTEGER PRIMARY KEY,option TEXT NOT NULL UNIQUE);CREATE TABLE option_desc (option_desc_id INTEGER PRIMARY KEY,option_desc TEXT NOT NULL UNIQUE);CREATE TABLE pkg_option (package_id INTEGER NOT NULL REFERENCES packages(id) ON DELETE CASCADE ON UPDATE CASCADE,option_id INTEGER NOT NULL REFERENCES option(option_id) ON DELETE RESTRICT ON UPDATE CASCADE,value TEXT NOT NULL,PRIMARY KEY(package_id, option_id));CREATE TABLE pkg_option_desc (package_id INTEGER NOT NULL REFERENCES packages(id) ON DELETE CASCADE ON UPDATE CASCADE,option_id INTEGER NOT NULL REFERENCES option(option_id) ON DELETE RESTRICT ON UPDATE CASCADE,option_desc_id INTEGER NOT NULL REFERENCES option_desc(option_desc_id) ON DELETE RESTRICT ON UPDATE CASCADE,PRIMARY KEY(package_id, option_id));CREATE TABLE pkg_option_default (package_id INTEGER NOT NULL REFERENCES packages(id) ON DELETE CASCADE ON UPDATE CASCADE,option_id INTEGER NOT NULL REFERENCES option(option_id) ON DELETE RESTRICT ON UPDATE CASCADE,default_value TEXT NOT NULL,PRIMARY KEY(package_id, option_id));CREATE TABLE shlibs (id INTEGER PRIMARY KEY,name TEXT NOT NULL UNIQUE );CREATE TABLE pkg_shlibs_required (package_id INTEGER NOT NULL REFERENCES packages(id)  ON DELETE CASCADE ON UPDATE CASCADE,shlib_id INTEGER NOT NULL REFERENCES shlibs(id)  ON DELETE RESTRICT ON UPDATE RESTRICT,UNIQUE(package_id, shlib_id));CREATE TABLE pkg_shlibs_provided (package_id INTEGER NOT NULL REFERENCES packages(id)  ON DELETE CASCADE ON UPDATE CASCADE,shlib_id INTEGER NOT NULL REFERENCES shlibs(id)  ON DELETE RESTRICT ON UPDATE RESTRICT,UNIQUE(package_id, shlib_id));CREATE TABLE annotation (annotation_id INTEGER PRIMARY KEY,annotation TEXT NOT NULL UNIQUE);CREATE TABLE pkg_annotation (package_id INTEGER REFERENCES packages(id) ON DELETE CASCADE ON UPDATE RESTRICT,tag_id INTEGER NOT NULL REFERENCES annotation(annotation_id) ON DELETE CASCADE ON UPDATE RESTRICT,value_id INTEGER NOT NULL REFERENCES annotation(annotation_id) ON DELETE CASCADE ON UPDATE RESTRICT,UNIQUE (package_id, tag_id));CREATE TABLE pkg_conflicts (package_id INTEGER NOT NULL REFERENCES packages(id)  ON DELETE CASCADE ON UPDATE CASCADE,conflict_id INTEGER NOT NULL,UNIQUE(package_id, conflict_id));CREATE TABLE provides(    id INTEGER PRIMARY KEY,    provide TEXT NOT NULL);CREATE TABLE pkg_provides (package_id INTEGER NOT NULL REFERENCES packages(id)  ON DELETE CASCADE ON UPDATE CASCADE,provide_id INTEGER NOT NULL REFERENCES provides(id)  ON DELETE RESTRICT ON UPDATE RESTRICT,UNIQUE(package_id, provide_id));CREATE TABLE requires(    id INTEGER PRIMARY KEY,    require TEXT NOT NULL);CREATE TABLE pkg_requires (package_id INTEGER NOT NULL REFERENCES packages(id)  ON DELETE CASCADE ON UPDATE CASCADE,require_id INTEGER NOT NULL REFERENCES requires(id)  ON DELETE RESTRICT ON UPDATE RESTRICT,UNIQUE(package_id, require_id));PRAGMA user_version=2014; in file pkgdb.c:2320: disk I/O error
Unable to create repository OPNsense
Unable to update repository OPNsense
Error updating repositories!
pkg: Repository OPNsense cannot be opened. 'pkg update' required
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***


Doing the same for a second time came up with the update to 23.1_6 which I successfully installed.

Just wondering what this hiccup was ...

Hi all,

I've recently updated my OPNsense from 22.1.10 to 22.7.2 and noticed one regression that I haven't been able to solve yet.

I'm on a German Telekom VDSL dual IP stack via PPPoE where LAN has a static IPv4 with DHCPv4 and track6 for IPv6 with DHCPv6 also enabled.

The LAN interface on the OPNsense looks like:

Code Select Expand


igb1: ...
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        inet6 fe80::xxxx%igb1 prefixlen 64 scopeid 0x2
        inet6 2003:de:yyyy prefixlen 64


On the OPNsense, after an WAN IP renewal, I get the following behaviour:

Code Select Expand


root@opnsense:~ # host www.google.com 127.0.0.1
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:

www.google.com has address 172.217.16.164
www.google.com has IPv6 address 2a00:1450:4016:80c::2004


root@opnsense:~ # host www.google.com ::1
Using domain server:
Name: ::1
Address: ::1#53
Aliases:

www.google.com has address 172.217.16.164
www.google.com has IPv6 address 2a00:1450:4016:80c::2004


root@opnsense:~ # host www.google.com 192.168.1.1
Using domain server:
Name: 192.168.1.1
Address: 192.168.1.1#53
Aliases:

www.google.com has address 172.217.16.164
www.google.com has IPv6 address 2a00:1450:4016:80c::2004


root@opnsense:~ # host www.google.com 2003:de:yyyy
;; connection timed out; no servers could be reached


As you can see, dnsmasq is working for all but the LAN's IPv6 address. Only after a restart of the dnsmasq service, I also get it running on the IPv6 address:

Code Select Expand


root@opnsense:~ # host www.google.com 2003:de:yyyy
Using domain server:
Name: 2003:de:f724:b400:2a1:ecff:fe68:f1c0
Address: 2003:de:f724:b400:2a1:ecff:fe68:f1c0#53
Aliases:

www.google.com has address 172.217.16.164
www.google.com has IPv6 address 2a00:1450:4016:80c::2004


1) Is this a know issue or a configuration problem of my setup?

2) If so, how can I fix it?

Greetings,
Stefan

Hi all,

I noticed on the dashboard that the used space on /var/log increased recently. So I did a "du --si -s *" in /var/log and found the subfolder dhcpd as the culprit:

Code Select Expand


root@opnsense:/var/log/dhcpd # ls -al
total 3573809
drwx------   2 root  wheel          34 Apr 12 11:01 .
drwxr-xr-x  20 root  wheel          44 Apr 12 09:21 ..
-rw-------   1 root  wheel      244116 Mar 13 23:57 dhcpd_20220313.log
-rw-------   1 root  wheel      219833 Mar 14 23:55 dhcpd_20220314.log
-rw-------   1 root  wheel      208801 Mar 15 23:59 dhcpd_20220315.log
-rw-------   1 root  wheel      207357 Mar 16 23:58 dhcpd_20220316.log
-rw-------   1 root  wheel      198017 Mar 17 23:55 dhcpd_20220317.log
-rw-------   1 root  wheel      211938 Mar 18 23:57 dhcpd_20220318.log
-rw-------   1 root  wheel      220304 Mar 19 23:55 dhcpd_20220319.log
-rw-------   1 root  wheel      207230 Mar 20 23:59 dhcpd_20220320.log
-rw-------   1 root  wheel      203665 Mar 21 23:59 dhcpd_20220321.log
-rw-------   1 root  wheel      224149 Mar 22 23:59 dhcpd_20220322.log
-rw-------   1 root  wheel      216169 Mar 23 23:59 dhcpd_20220323.log
-rw-------   1 root  wheel      223937 Mar 24 23:57 dhcpd_20220324.log
-rw-------   1 root  wheel      220520 Mar 25 23:59 dhcpd_20220325.log
-rw-------   1 root  wheel      229024 Mar 26 23:56 dhcpd_20220326.log
-rw-------   1 root  wheel      271634 Mar 27 23:55 dhcpd_20220327.log
-rw-------   1 root  wheel      251120 Mar 28 23:56 dhcpd_20220328.log
-rw-------   1 root  wheel      265486 Mar 29 23:55 dhcpd_20220329.log
-rw-------   1 root  wheel      272309 Mar 30 23:55 dhcpd_20220330.log
-rw-------   1 root  wheel      264335 Mar 31 23:56 dhcpd_20220331.log
-rw-------   1 root  wheel      304474 Apr  1 23:55 dhcpd_20220401.log
-rw-------   1 root  wheel      260829 Apr  2 23:55 dhcpd_20220402.log
-rw-------   1 root  wheel  1493859272 Apr  3 23:59 dhcpd_20220403.log
-rw-------   1 root  wheel  6547501137 Apr  4 23:59 dhcpd_20220404.log
-rw-------   1 root  wheel  6512845136 Apr  5 23:59 dhcpd_20220405.log
-rw-------   1 root  wheel  6516743124 Apr  6 23:59 dhcpd_20220406.log
-rw-------   1 root  wheel  6675526139 Apr  7 23:59 dhcpd_20220407.log
-rw-------   1 root  wheel  6508607429 Apr  8 23:59 dhcpd_20220408.log
-rw-------   1 root  wheel  6483174952 Apr  9 23:59 dhcpd_20220409.log
-rw-------   1 root  wheel  6720341313 Apr 10 23:59 dhcpd_20220410.log
-rw-------   1 root  wheel  6940561135 Apr 12 00:00 dhcpd_20220411.log
-rw-------   1 root  wheel  3513974130 Apr 12 11:40 dhcpd_20220412.log
lrwxr-x---   1 root  wheel          33 Apr 12 11:01 latest.log -> /var/log/dhcpd/dhcpd_20220412.log


First I assumed that the last 7 (or 10) days would be plaintext and older ones are compressed, but this is not the case.

It could be connected to an upgrade from 22.1.x to the latest 22.1.5, but I'm not sure how to verify that.

Any ideas?

Hi all,

when using track6 on the LAN interfaces, can something be configured that local clients' IPv6 addresses are registered as AAAA records when using dnsmasq?

TIA.

Greetings,
Stefan

Hi all,

I have implemented a setup as explained at https://pi-hole.net/2021/09/30/pi-hole-and-opnsense/ (including unbound behind the Pi-hole - however on the Pi-hole itself and not back to OPNsense). It is a working setup with correct name resolution of local names, filtering in the Pi-hole and recursive resolution using unbound. Check to all those. However ...

Let's assume that local.my.domain is configured as local domain in OPNsense (my.domain being a placeholder for domain that I own and that is registered to myself).

While queries for somehost.local.my.domain are correctly answered by dnsmasq on the OPNsense with the via DHCP registered IP address (however only IPv4 - this may be another point, see below), I then realized that DNS queries for nonexisting.local.my.domain leave the OPNsense and dnsmasq forwards the queries the Pi-hole, which forwards to unbound which then queries the public name server for my.domain, so the query for a non-existing (!) local hostname leaks out to some upstream name server.

I ended up adding the following configuration to the unbound configuration

Code Select Expand


server:
    local-zone: "local.my.domain." always_nxdomain
    local-data: "local.my.domain. 3600 IN SOA opnsense.local.my.domain. etc. etc. etc."


so that I stop the leakage at least at the unbound level before leaving my network.

However, shouldn't dnsmasq on the OPNsense not even forward queries if they refer to the local domain? Shouldn't OPNsense be authoritative for the local.my.domain and only forward queries for other domains it is not authoritative for?

Even if there is a valid reason for that behaviour: Can it be turned off somehow?

And a second question: Can I also get OPNsense to register IPv6 addresses to dnsmasq so that also AAAA records can be answered?

TIA.

Greetings,
Stefan

Hi all,

from time to time I see packets blocked incoming to LAN interface from the LAN net with the label "Default deny rule" even though LAN has configured the "Default allow LAN to any rule".

Shouldn't the "Default deny rule" from the automatically generated floating rules be "last match" and therefore the "Default allow LAN to any rule" should match before?

And even, if the destination IP was in "Malicious IPs", then the label of the match shouldn't be "Default deny rule".

So, I'm really puzzled what I'm seeing there. Could anybody please explain to me how this can happen? What part of the workings of the firewall am I misunderstanding?

BTW: I noted that the LAN IPs where this originates from are Fire TV and Android devices, but that can of course be coincidence.

Thanks in advance.

Greetings,
Stefan

Hallo zusammen,

ich habe ein kleines Unifi-Netzwerk bestehend aus einem Unifi Security Gateway, einem Unifi Switch und zwei Unifi Access Points und bin nun dabei, das USG gegen eine OPNsense auszutauschen.

Die OPNsense (21.7.4) ist virtualisiert auf einem Proxmox VE und WAN sowie LAN Port sind per PCI Passthrough direkt an die OPNsense geleitet.

Ich habe den Umstieg von USG auf OPNsense quasi vollzogen und eigentlich funktioniert schon fast alles: IPv4/IPv6 Dual Stack (Telekom PPPoE via Vigor - inkl. Management-Zugriff), DHCP, DNS (inkl. Pihole und Unbound), Dynamic DNS, Firewall-Regeln (inkl. Port Forwarding und NAT Reflection).

Das einzige, womit ich noch kämpfe, ist ein Gäste-WLAN mit eigenem VLAN. In der Unifi-Welt war das einfach, da der Controller alles durchgängig vom USG über den Switch zu den APs entsprechend provisioniert. Jetzt - ohne USG - scheine ich irgendwas mit dem VLAN-Tagging noch nicht korrekt zu haben und brauche Hilfe.

Der relevante Teil sieht in etwa so aus:

Code Select Expand


            |
      .-----+------.
      |  OPNsense  +
      '-----+------'
            |
        LAN | 192.168.1.0/24   igb1
     Guests | 192.168.99.0/24  igb1_vlan99
            |
      .-----+------.
      | LAN-Switch |  (Unifi Switch)
      '-----+------'
            |
        LAN | 192.168.1.0/24
     Guests | 192.168.99.0/24
            |
      .-----+------.
      |  Wifi-AP   |  (Unifi Access Point)
      '------------'


Auf Unifi-Seite habe ich das alte "Gast-Netzwerk" zu einem "VLAN-only-Netzwerk" umgestellt. Switch Port "all" (der Default) beinhaltet LAN untagged und Gast-Netz tagged. Auf dem Unifi-Switch wird mir das auch so angezeigt, wenn ich die laufende Config anschaue (cat /tmp/running.cfg):

switch.managementvlan=1
switch.vlan.1.id=1
switch.vlan.1.mode=untagged
switch.vlan.1.status=enabled
switch.vlan.2.id=99
switch.vlan.2.mode=tagged
switch.vlan.2.status=enabled

Auf der OPNsense habe ich igb1 als Parent-Interface für LAN und igb1_vlan99 als das Gastnetz-Interface:

igb1_vlan99: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether ...
        inet 192.168.99.1 netmask 0xffffff00 broadcast 192.168.99.255
        inet6 ...
        groups: vlan
        vlan: 99 vlanpcp: 0 parent interface: igb1
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Verhalten ist nun Folgendes:

Wenn ich mich per WLAN ins Gastnetz einwähle, erhalte ich per DHCP die erste Lease als 192.168.99.10 zugewiesen (das taucht auch sowohl in der OPNsense unter Leases als auch im Unifi Controller auf, allerdings dort mit 0% Experience). Neben der IP bekomme ich auch korrekt Domain Name, Domain Search, DNS, etc. zugewiesen - für IPv4 ebenso wie für IPv6.

Allerdings habe ich kein Netz: Ich kann von der 192.168.99.10 nicht einmal das Gateway 192.168.99.1 pingen - geschweigedenn andere Netze. Mit "tcpdump -i br0.99" und "tcpdump -i eth0.99" auf dem Access Point sehe ich allerdings auch Traffic (DHCP hat ja auch funktioniert).

Firewall Regeln sind derart, dass aus dem Gast-Netz kein Zugriff ins LAN (und umgekehrt) ist, aber ansonsten Gast-Netz erstmal alles darf. Ich sehe im Live View der OPNsense auch keine blockierten Einträge, wenn ich z.B. den o.g. Ping absetze, daher gehe ich naiv nicht davon aus, dass es an den Firewall-Regel liegt.

Sieht jemand sofort, woran es liegt und was der Fehler ist?

Wenn nicht, was sind die nächsten Schritte, um das zu Debuggen?

Vielen Dank und viele Grüße
Stefan