Messages

I think I'm already past that stage.

What I've tried until now:


One of the first things that I tested today: created a floating rule on top for all interfaces to allow access to port 443 on "this firewall". Same behaviour: I see that this rule is then hit before my network-specific rule for access to port 443 on the firewall, again in the green, rule hit with pass. However, same behaviour, no web interface loading.

The web ui only loads over the LAN-bridge, which is the only bridge not linked to a vlan interface. All other bridges are linked to a VLAN interface. The Lan-bridge was created initially during install and has the web ui access, without VLAN.

Maybe also interesting to mention: even already used the firewall-settings to disable packet filtering, basically disabling whole firewall: still no access to web ui from that specific network segment.

Also tried completely disabling firewalld on the hypervisor, in the assumption that this was blocking something, also no luck.

My instinct is telling me it's almost as if the vlan tagging is disappearing when the response packets are coming from the opnsense vm to my laptop, but I don't see how that's possible.

For the hypervisor itself it's working, I can SSH to it over that same bridge in that same VLAN.

It's just your normal eth0 -> eth0.100 -> bridge100 setup, so as I understand it, it's not necessary to do any further config on the hypervisor side to keep those VLAN tags.

The packets coming from the opnsense VM over that bridge will automatically be tagged with the correct bridge right?

What I am wondering at the moment; I just read this article:

https://computingpost.medium.com/create-linux-bridge-on-vlan-interface-in-debian-11-10-e5679e3894bd
This is basically what I did, times 7.

Especially this part I found interesting:

echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.conf.all.arp_filter=0" | sudo tee -a /etc/sysctl.conf
echo "net.ipv4.conf.all.rp_filter=2" | sudo tee -a /etc/sysctl.conf

=> I didn't make these changes on my hypervisor, but I'm wondering if these could explain the behaviour I'm seeing.

Especially since these settings appear to be relevant for multihomed machines but also to determine on which interface to send replies...

I'm still wondering if the ip_forward is even necessary. But those other 2 settings I think I would need to check.

I have been banging my head for hours over the following, but can't figure out where my problem could be.

I am running an opnsense (latest release) in a KVM hypervisor on linux.
I have it connected to a trunk port on a managed switch.

I've decided to configure the VLAN interfaces on the level of the hypervisor as follows:
- for every VLAN on the trunk a VLAN interface on the hypervisor
- for each of those VLAN interfaces a bridge has been created
- these bridges are then attached to my opnsense VM, who manages the traffic in between (basically opnsense isn't aware that underneath VLAN's are in use, it's handled on the hypervisor level).

Now I want to make the opnsense web ui accessible on one of those VLAN's.
I have the web ui listening on all interfaces.
I also have a firewall rule which allows traffic to port 443 on the firewall interface in that specific network segment.

I am now connected from my laptop to that same managed switch via a port which has that same vlan configured as an untagged port.

My hypervisor also has an IP on the bridge in that same VLAN.
I can successfully ssh from my laptop, so in that VLAN, to the hypervisor and login.
I can however NOT connect to the webui of opnsense in that same VLAN.

When I look in the firewall logs of opnsense, I see that the rule I configured for access to the firewall interface on port 443 from that specific VLAN/network segment is hit, it goes green and is a rule of type "pass".
So from the firewall rules, it seems as if I'm hitting the correct rule with a pass.

However, the Web ui is not loading and I can not access it.
I have no idea where the root cause of this problem could be, anybody here perhaps an idea?

So after some more online searching, am I correct that the best way is:

- configure vlan's on the hypervisor level linked to the physical LAN-NIC
- Create a bridge for every one of those VLAN's, but without an ip address configured
- add these vlan-bridge-interfaces in OPNSense as actual interfaces and then configure IP, DHCP, firewall rules, ... on the level of OPNsense


Is this the way most would handle this?
So basically you configure the VLAN's on the level of the host/hypervisor, the guest (opnsense in this case) isn't even aware of these VLAN's and just sees them as basic "physical bridge interfaces"?

Does this mean that you don't follow the flow in opnsense to add VLAN's (basically you do NOT add them as VLAN interfaces as described here: https://docs.opnsense.org/manual/other-interfaces.html#vlan )?
Since OPNSense doesn't see the VLAN's, but considers them as physical interfaces/bridges, you just add them as standard interfaces?

Or am I wrong in my understanding here?

I also read about openvswitch, but honestly, I don't want to go this route, I don't expect a lot of VLAN's, so configuring VLAN-to-bridge interfaces on the hypervisor level isn't really an issue for me.

Hi all,



I currently have the following setup:
- OPNsense virtualized, not using proxmox but using your basic kvm
- hosted on a machine with 2 physical NIC's
- the WAN is a bridge on one physical nic, the LAN is a bridge on the other physical nic.


I now also want to add VLAN segmentation on the LAN-side using a managed switch which should arrive any day now.

But I was just wondering: how would I need to configure the VLAN's in combination with the LAN bridge on the OPNsense side?
Will that even work?

Thanks for any info you can give!

Hi all,


I'm currently wondering what would be the best and most secure approach to do a new install in a cloud-environment?

So basically I can have a VM where opnsense is installed, but since it's a cloud environment, the only thing I have is a console access to the VM.

Network-wise, after install, I can only reach the VM from the WAN-side, where the GUI is blocked by default.

I want to get to the situation where I can use a VPN to connect to the firewall and then access the GUI over that VPN.
However, I first need to get to the GUI before being able to configure a VPN, chicken or the egg problem :)

So how would you approach something like this?

If I have it correctly, enabling SSH access via the console is not possible, adding firewall-rules to temporarily enable GUI access over the WAN is not possible via the console, ...

How do others tackle this?

Thanks for any input you can give here!

I think I found the same issue via the github repo's.

https://github.com/opnsense/core/issues/5639
https://github.com/opnsense/core/commit/28e7d49380624e787319ca4ca8bb59b7d15e231f

So, looking at the reporter there, my machine has similar specs.
Considering the feedback:
"The machine isn't fast enough to wait for the action to complete (120 seconds), 28e7d49 changes the log level to notice (which is more suitable)."

Does this mean that the dns blocklists actually work as expected, this isn't really a fatal error and we can safely ignore this?
It's because the machine isn't the most performant one, that this triggers a timeout but actually finishes correctly in the background anyways?

You mean using less lists?
I'm wondering where this timeout is occurring. It doesn't seem to be in the dowloading of the lists themselves from what I can see.

In the processing?
Why not increase this timeout?

I mean, if you provide all these blacklists in the dropdown selection field, then shouldn't the opnsense script that processes them be written in such a way that worst case a full selection of the entire list is possible?

Ok, sorry for this, but seems I can't upload all attachments in one post.

Hi,


Have been experiencing regular issues while using the unbound DNS service with DNS blocklists.

More specifically: let's say I want to add some blocklists and download&apply them (see attachment - 1.PNG).
It proceeds with downloading as seen in the unbound log, which seems to complete successfully. (2.png and 3.png)

However, the DNS console shows an error (see 4.png).
In the logs, the only thing I can find is "Timeout (120) executing: inbound dnsbl". (see 6.png)

Now, in this case, I'm lucky, my DNS service still seems to be running, despite the error message.
More often than not, once I click away the error message and refresh, I see the red arrow at top right indicating stopped service. (as in 7.png)

Anyways, to be sure, I manually restart the unbound DNS service.

I'm again seeing error messages in logs: see 8.png.
But the service seems to start and to resolve DNS queries, taking into account the blocklists (e.g. known porn lists are blocked based on the selected porn blacklists).

The above behavior occurs EVERY time I manually trigger a download & apply on the DNS blacklists.

I also have a cron job which refreshes the blocklists every night in the middle of the night.
When I go online in the morning, DNS resolving still seems to work, so it seems the service does not stop in the night when updating the blocklists.

So I'm a bit in doubt here.
Is there an issue with the unbound DNS blocklist, is this only an issue when doing a manual trigger, ...

Thanks for any insight you can provide!