Messages

Any guidance on how to properly update the vlan naming without blowing up everything?

i see i was a bit late as you've already got it done, but here's how i did it:

- make sure you can reach the firewall from atleast 2 networks (i used my main machine + smartphone on 2 different vlans)
- create a temporary useless vlan
- go to assignments, take your main machine vlan, change it to the useless vlan you just created

(you'll no longer be able to access the fw through your main machine)

- login with your phone
- go back to devices, update the name
- back to assignments, setting the original vlan back to it's right assignment, save, and for good measure, restart dhcp (because this one now has no clue for dhcp on your newly named original interface)

then, repeat the process for all other vlans, which you can now comfortably do from your main machine, and then restart dhcp so all interfaces are picked up.

(and to end, if you added temporary rules for your phone to access the firewall, remove them once done -ofcourse)

bonus: to be sure that you don't completely F up, also go to snapshots, create a new snapshot before starting, and set the unchanged config to next-active.
if things go wrong, just reboot the firewall so it ends back up at the previous config and you can start over without having locked yourself out.
once finalized, set your changed config to be the next-active again.

i'm not sure when the switch from interface_vlanx to vlan0.x was implemented, but for my current machine (installed 2 years ago i believe - not sure if it was a clean install or still also an import back then) it was still with interface__vlanx and that was causing several issues with the current version (like when i updated mtu on an interface that interface just became unreachable - but after updating the device name it worked fine)

but, if you are aware of this (maybe it was mentioned in changelogs... should really start reading those again), then it's not too much of a big deal to update them as long as you have an alternate interface available.
in case of a restore however, i can very much see how this will break things.

Apparently my naming is old and has the interface name in the name (ix0_vlan10)

this is also something i had noticed after my last upgrade.
i think it's a good idea to move to that (standard?) naming for vlans, but they might want to have had something to prevent legacy machines from breaking on it (like automatically changing the names when upgrading, if that would be possible for example)

the best solution would just indeed be updating the configs to be vlan0.x instead of ix0_vlanx
the "maybe the devs can think of old users" option would be to have something in the restore that catches old naming conventions and automatically updates it.

i think it's just a scenario that's not been thought of to test (old interface naming of vlans, and restoring that to a different host is likely not a daily use case)

guess i'll be adding the "update vlan naming" to my todo list as well before i get bitten in the same way you did.

i am fairly certain that previously (24.x was the last time i checked the graph - i think) i did not have the lan_default showing the traffic like this,
though i can follow your logic as to the physical parent interface counting all traffic (but it should still be able to be sorted out in the graphs i think?)

same goes for some other things btw (a very long time ago, setting up new interfaces allowed some more free naming, such as using igc1_vlan1006 instead of the much more normal vlan0.1006 that should've been used)

anyway:
the physical interface is igc1
the lan_default is the default network that's auto-created on the interface (identifier lan on parent igc1)
the vlans, obviously, are igc1_vlan1002 and igc1_vlan1006
they have interface 1002_servers (opt2) and 1006_security (opt6)
(as stated; under vlan interfaces, they are still known by their old interface names, which were accepted back then - such as igc1_vlan1006 - something no longer possible for new ones as it -quite correctly- needs to be vlan0.1006 )


just for my information, i'm assuming when you say that you shouldn't use the parent interface, you mean that it should've had vlan0.1 as a default vlan interface, right (and then have the switch handle it)?

(again though, history reasons: there was a lan_default, that was i believe not even removable long ago, plus untagged access needed to be possible, and the original setup dates back from when it was on esxi, so there is def. some improvement to be made)

in short: yes, i agree with you that the setup isn't ideal (working on it to get it to where it needs to be, step by step when i have time),
but i don't remember the graphs behaving like this before, which is why i created the post (as opposed to a bug report, because in itself, it's not going to be a bug - likely just some change somewhere to the behaviour)

alas, nobody having any similar experiences ?

i don't want to open a bug report because i'm not sure if it's "just my installation", something i have overlooked, or an actual bug...

so if anyone here is doing router-on-a-stick and has a few vlans, i would appreciate some input if you're seeing similar results (i.e. the default lan on the interface showing the same traffic (both in & out) that's actually passing between 2 vlans)

No, it doesn't. A DNS resolver never adds domains to the client's query.

true, bad wording on my part, i should have said 'then the client' instead of 'it' which implied adguard itself.
for that matter, i probably should also have said "adds your search domain to the domain" instead of just "domain to the domain"
.... time to leave the computer for the day :)

ok, so what's happening is basically:

adguard tries to resolve a host (fails due to blocklist)
then it adds your domain (which usually is internally only) to the domain, and tries again

if you have adguard setup to forward all (non-blocked) queries to unbound, then you will have to verify in unbound if the query was leaked onwards to upstream,
or if opnsense/unbound responded with a result from the local registry.

it's been ages since i messed with dns split brain config, because keeping track of internal & external routing and authoritative responses is... annoying,
which is one of the (multiple) reasons to just use an internal hostname on your network.
(that's not to say you can't do it though)


you could setup a rule in adguard that it sends all queries to an external dns server directly instead of opnsense, and then route only croapino.com back to unbound (settings/dns settings/upstream dns servers : [/croapino.com/]127.0.0.1:8953 )
also go to unbound / advanced / general and set private domains to croapino.com in opnsense so the domain is allowed to have private IPs in it.

i can't guarantee it will work completely, but in this situation your client will query adguard for the domain,
adguard will block and then add the full hostname, then see that queries for that hostname need to be sent to opnsense, and opnsense should respond with either a failure or a resolved host for a local machine, without going to any upstream dns server.

... it could also end up looping back to adguard if it tries to resolve it though, so do check your logs when trying this change :)

aguard is not "useless" - it is doing exactly what it is required: resolve domains.
the fact is, you do not have a rule to block subdomains for "croapino.com", so they get resolved.

this is likely being added due to your domain that's been set in opnsense and assigned to try to query it if a lookup fails.
the better question is: if you do not own the croapino.com domainname, why did you configure it (instead of, say, local.internal) ?

it shouldnt have anything to do with the private reverse resolving, because it's trying to resolve a domain, not an ip.

Versions:
OPNsense 25.1.7-amd64
FreeBSD 14.2-RELEASE-p3
OpenSSL 3.0.16

Setup:
2 WAN connections, 1 physical connection to switch, several VLANs, crowdsec & ips (from the "regular" intrusion detection) active on both WAN interfaces, maltrail active on all VLANs, and network configured as router-on-a-stick.

Issue:

I am running ip cams on vlan 1006, which are being streamed to my nas on vlan 1002

The traffic graph correctly shows the traffic of both interfaces, BUT:

it is also showing that exact same traffic going over the default, untagged vlan ("lan_default") where there is no real traffic.
the "top hosts" dots are also showing correctly that there's pretty much no traffic on that default vlan, but the graphs itself do not (see attached screenshot, showing only that default lan)

this same inconsistency also shows on insights, and is not fixed by a reboot, reset of netflow/rrd data, or repair of netflow data.

i've been using opnsense for years, and admittedly i changed too much at once (updating to 25.1.7, rebuilding fw rules back mostly to interface instead of floating because of the number of rules, ....) but have never had an issue like this (that wasn't fixed by resetting the graphs or just rebooting the machine)

so, does anyone have any idea where to go look for this issue ?

aaand.... after a decent night sleep and some coffee i went ahead and actually enabled the haproxy service in the config to solve this  ::)

could do with a "make sure the service is enabled" addition to the message...
but then again, could also just notice the fact that the status button is not shown, so... more coffee and sleep.

So, while i had no issues on a 21.7.5 machine, i just setup a new opnsense,
so a completely NEW setup, no tinkering, no importing, no whatever.

while configuring haproxy i keep running into the issue that it says "There are pending configuration changes that must be applied in order for them to take effect. To review them visit the Config Diff page."
and when i hit apply.... it does not apply.
and so, no way to start haproxy.

when i move haproxy.conf.staging to haproxy.conf manually, and start haproxy manually, there is no issue and the gui happily says there are no config changes.
i then change something in the gui again aaaaaand.... broken again.

is this a known issue for 21.7.7 ?
is someone else experiencing this ?

we have opnsense support if needed, so i could always contact their paid support, but before bothering them  like that,
i wanted to verify in the community if anyone else is seeing this.

as i was looking back through the forums (dont come here too often) and github i was compelled to donate as well.
i know deciso has income from their enterprise offerings, but hey... they are offering a great product for free, and listening and helping the community out, so the community should do the same.

since i've been using opnsense since practically the beginning and would recommend everyone this over any other firewall,
we'll go for the monthly donation here as well.
and since 3 euro seems to be the going rate, that's what we'll chip in !

Welcome to the opnsense fanbase :)

This is (probably) due to the current filter being applied to interface, but not to the network of that interface.
That means any traffic captured coming or going over the interface gets logged.

There is now an issue on github to discuss and perhaps change this behaviour: https://github.com/opnsense/core/issues/4724

A very understandable question.

This is (probably) due to the current filter being applied to interface, but not to the network of that interface.
That means any traffic captured coming or going over the interface gets logged.

There is now an issue on github to discuss and perhaps change this behaviour: https://github.com/opnsense/core/issues/4724

Franco: i updated from the 19.1 series to 19.7.3 and also noticed the cpu load...
which is now almost constantly at 95%, seemingly due to suricata and netflow.
(with suricata often logging Error reading data from iface 'pppoe0': (55u) No buffer space available )

both suricata and netflow were already running on 19.1 where i had, maybe, a 10% load (so the cpu load jumped extremely high, even in low-traffic situations)
i dont know what buffer space would be needed, but there is enough free disk space and memory as well as swap space, so that cannot be an issue.

since turning off suricata and netflow is not an option, i was wondering if it is possible to downgrade back to 19.1?
(i would rather stay on an outdated firewall than to disable functions or use -and thus pay- a lot more electricity, since this is a 24/7 appliance)

i currently kill the involved processes (suricata, netflow, syslog-ng) and then have a relatively stable, normal cpu usage for a while... but it seems to return to high usage after some time for no clear reason