Messages

Yes to all... this is the problem when you work with newbies; so much to get wrong.

I took a step back and set-up a test environment, simplified to the bare bones.
First test and validate switch config.
1. 4 access ports, 1. Proxmox (no OPNsense), 2 clients --> all pings in any direction
2. change Proxmox port to access and added this config --> all pings in any direction
Though the config seems excessive?!

Code Select Expand

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

iface enx0050b61f9434 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.2.2/24
    gateway 192.168.2.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
#LAN bridge (untagged, native VLAN)

auto vmbr1
iface vmbr1 inet manual
    bridge-ports none
    bridge-stp off
    bridge-fd 0
#WAN bridge

auto vmbr10
iface vmbr10 inet manual
    bridge-ports eno1.10
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 10
#LAN VLAN 10 (tagged)

auto eno1.10
iface eno1.10 inet manual
    vlan-raw-device eno1
#VLAN 10 subinterface

source /etc/network/interfaces.d/*

which evolved to:

Code Select Expand

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto enx0050b61f9434
iface enx0050b61f9434 inet manual
#WAN (no VLAN)

auto vmbr0
iface vmbr0 inet static
    address 192.168.2.2/24
    gateway 192.168.2.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 10,30,40,50
#LAN bridge (untagged + VLANs 20,30,40,50)

auto vmbr1
iface vmbr1 inet static
    address 192.168.1.2/24
    bridge-ports enx0050b61f9434
    bridge-stp off
    bridge-fd 0
#WAN bridge (no VLAN)

source /etc/network/interfaces.d/*

... after I created VNets:

Code Select Expand

cat /etc/pve/sdn/vnets.cfg
vnet: vnetlan
    zone vlanzone
    alias VNet LAN
    tag 10

vnet: vnetdmz
    zone vlanzone
    alias VNet DMZ
    tag 30

vnet: vnetiot
    zone vlanzone
    alias VNet IoT
    tag 40

vnet: vnetgst
    zone vlanzone
    alias VNet Guest
    tag 50

... with this zone:

Code Select Expand

cat /etc/pve/sdn/zones.cfg
vlan: vlanzone
    bridge vmbr0
    ipam pve

Now the questions:
1. is this configuration suitable for installing OPNsense in a VM on this Proxmox machine?
2. What I mean, other than having to configure OPNsense, there is no further config on Proxmox required?! Correct?
3. When going through the OPNsense setup in the CLI is it correct to select the VNets and not vmbrs (except for WAN) as interface for the LAN, DMZ, IOT, Guest networks?
4. Anything else I need to do to not log me out of Proxmox or OPNsense? :)

Thank you... yes, I connected the NIC to the trunk port. (Apologies for not being specific enough).

How do people set this up without loosing connection to Proxmox and OPNsense?

I have reverted back to what I had working, though without VLANs.

I probably should have attached my switch config too... (now attached).

In any case I will try your config. I was close... :) but missed the VLAN lines.

Code Select Expand

auto vmbr0
  iface vmbr0 inet static
  bridge-ports eno1
  bridge-stp off
  bridge-fd 0
#LAN

auto vmbr0.20
iface vmbr0.20 inet static
  address 192.168.2.2/24
  netmask 255.255.255.0
  gateway 192.168.2.1
#VLAN20

Is there anything else I can post to provide more clarity.?

Over the course of four weeks and endless hours I have tried to get SDN VLANs going; to no avail.

Proxmox 9.09. OPNsense 25.7.5

The following current config without any VLAN-ing is working.

On Proxmox I have:
- vmbr0 = LAN (NIC) 192.168.2.0/24
- vmbr1 = WAN (USB->Ethernet) 192.168.1.118 gw 192.168.1.1 (to get Internet connectivity for updates, etc.)
- vlanzone (ZONE VLAN)
- vnetlan in vlanzone (no subnets) VID 20
- OPNsense VM with
  - virtio net0 vbmbr0
  - virtio net1 vbmbr1

On OPNsense I have:
- vlan01 for LAN (not assigned)
- LAN vtnet0 VID 20
- WAN vtnet1

Managed switch: FS.com S3700-24T4F
- port 1 default, no VLAN tag = Proxmox
- port 2 default, no VLAN tag = PC 192.168.2.100

As mentioned, the above config works.


Now, this is what I do to get VLANs configured.

Proxmox:
- change net0 from vmbr0 to vnetlan (if I do this first I loose access to Proxmox)

OPNsense:
- change vtnet0 to vlan01

Managed switch: FS.com S3700-24T4F
- ports 13-18 on VLAN 20 access
- port 23 trunk

After these changes:
- I cannot ping anything
- cannot reach any console; except direct connect to Proxmox machine

Since I can't reach OPNsense, I have to get Proxmox back to get to the OPNsense VM shell and revert the interface assignments.

I have done this now too many times to count, and can for the life of me not figure out what I am doing wrong.

I have watched endless YouTubes, but cannot find SDN Proxmox OPNsense VLAN videos; yes, some of the combinations but not all of them.

I am now at a point where I need help with this config. If there is a means to pay someone knowledgeable, I will.

If the resolv.conf is manually configured on this system, this is the correct way.

Thank you; I do appreciate all the feedback I am getting.

It is actually clear to me now, why this has to be with a) the rule and b) resolv.conf. Having a nameserver where the server has neither a route nor access to it, it will not resolve, unless the firewall (and that's its job) provides access to it. In my case, my rule was correct, but the resolv.conf wasn't. Changing resolv.conf to point to firewall's interface (for the, here, DMZ network) allowed the server to reolve DNS. Both, resolv.conf and DNS rule need to exist for the name resolution to work.

Hmm, being the novice I am, changed the resolv.conf to:

Code Select Expand

# --- BEGIN PVE ---
search grenkowitz.lan
#nameserver 8.8.8.8
#nameserver 1.1.1.1
nameserver 192.168.3.1
# --- END PVE ---


# [2025-09-11 07:18] root@DNS ~ #
nslookup google.com
Server:         192.168.3.1
Address:        192.168.3.1#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.67.14
Name:   google.com
Address: 2404:6800:4006:80a::200e

... which resolves... not sure if the is was the correct way of doing, but it works. So does rule 2 now.

Try your "DMZ address" explicitly.

DMZ is 192.168.3.0/24 DMZ address is .1
nslookup google.com 192.168.3.1 --> works when rule 3 is disabled. (I also got rid of rule 1, actually had this one in LAN as well)

cat /etc/resolv.conf
# --- BEGIN PVE ---
search grenkowitz.lan
nameserver 8.8.8.8
nameserver 1.1.1.1
# --- END PVE ---

This setting is only used by OPNsense itselft, but not by Unbound DNS.

Hmm, I am not sure where to set the DNS servers for unbound, but I stumbled over "Rebind protection networks" in Services | Unbound | Advanced, and it lists all private networks, including 192.168.0.0./8. Is this a problem for my set-up?

---

While searching the web, I found this: "To set DNS servers for Unbound in OPNsense, navigate to Services > Unbound DNS > DNS over TLS to add encrypted upstream DNS servers like Cloudflare (1.1.1.1) or Quad9 (9.9.9.9), entering the server IP and the appropriate Verify CN hostname. Crucially, you must also blank out the DNS servers on the System > Settings > General page and disable the "Allow DNS server list to be overridden by DHCP/PPP on WAN" option to ensure Unbound exclusively uses your specified upstream servers."
Shall I try this?!

I am on latest OPNsense on Proxmox Debian VM.

I have been working on solving this puzzle for a few days now, and it is doing my head in.

I am preparing OPNsense to have a mail/web/vpn server in its DMZ.
The WAN (192.168.1.2) is connected to a FRITZbox (via exposed host).

I have 3 rules in the DMZ:
1. in IPv4 TCP LAN net * DMZ net 22 (allow SSH)
2. in IPv4 TCP/UDP DMZ net * DMZ address 53 (Allow DNS)
3. in IPv4* DMZ net * * * (Allow any for testing)

I have a Debian LXC in the DMZ that can ping (due to floating rule allowing ICMP), but cannot nslookup when rule 3 is disabled. It can nslookup when enabled.

So why is rule 2 not allowing DNS for this host?

I have DNS servers in System | Settings | General (9.9.9.9 and 1.1.1.1) using the WAN_GW.

Happy to provide more info; any hints appreciated.

Thanks MeyerG(u)ru :)

I actually read this post, but did not even understand half of it; however, at the time (actually a few days ago) I though this is interesting stuff and book-marked it, and I read it when I have set-up OPNsense and understand it (at least a bit) better.

Since posting I did some further research, and changed Firewall | NAT | Outbound to manual and added a rule (Interface: WAN, Source: 192.168.2.0/24, Translation: 192.168.1.2).

I also did pick up that the Proxmox VMBRs had firewall=1 set. Silly me accepted the default, but pondered why it would firewall it, rather than OPNsense.

In any case, I find this firewall business quite challenging... it is easily buggered up.

Again, thank you.

Now that I have working, yet very basic config, I trash it and rebuild based on my notes. The ultimate proof the documentation is right.

I am new to OPNsense. I have installed Proxmox v9 on a Lenovo M82, which has one NIC and an USB Ethernet adapter. It was connected to my existing LAN 192.168.1.0/24, and it was able to ping, nslookup and download its updates. I added two additional VMBRs to the VM config and named these (WAN, LAN, DMZ).

Then I installed OPNsense 25.7.2 maybe it was .1 and when I updated it, it become .2. During the CLI install part I assigned vtnet to the valid interfaces. WAN: vtnet1; LAN: vtnet0; optional: DMZ = vtnet2. I reassigned the LAN network to 192.168.2.0/24, WAN to 192.168.1.0/24, DMZ to 192.168.3.0/24. OPNsense added its auto-generated rules to all three networks.

The WAN is on the private network 192.168.1.0/24 going via .1 through a FRITZbox

The DMZ is not configured and indicates that: no rules have been defined.
I can access the LAN on 192.168.2.100; an address that has been assigned by dnsmasq where did add a DHCP range (100-200).

Code Select Expand

root@pve1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
      valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vmbr0 state UP group default qlen 1000
    link/ether 00:23:24:a0:3c:3c brd ff:ff:ff:ff:ff:ff
    altname enp0s25
    altname enx002324a03c3c
3: enx00e04c896ad5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vmbr1 state UP group default qlen 1000
    link/ether 00:e0:4c:89:6a:d5 brd ff:ff:ff:ff:ff:ff
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:23:24:a0:3c:3c brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.2/24 scope global vmbr0
      valid_lft forever preferred_lft forever
    inet6 fe80::223:24ff:fea0:3c3c/64 scope link proto kernel_ll
      valid_lft forever preferred_lft forever
5: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:e0:4c:89:6a:d5 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2e0:4cff:fe89:6ad5/64 scope link proto kernel_ll
      valid_lft forever preferred_lft forever
6: vmbr2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 0a:c5:e2:55:9c:00 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::f052:9aff:feb1:66c3/64 scope link proto kernel_ll
      valid_lft forever preferred_lft forever
7: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel master fwbr100i0 state UNKNOWN group default qlen 1000
    link/ether 36:e5:d3:e9:a7:76 brd ff:ff:ff:ff:ff:ff
8: fwbr100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether c2:b0:4a:94:c3:0f brd ff:ff:ff:ff:ff:ff
9: fwpr100p0@fwln100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether a6:5b:2c:2c:a0:a3 brd ff:ff:ff:ff:ff:ff
10: fwln100i0@fwpr100p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i0 state UP group default qlen 1000
    link/ether c2:b0:4a:94:c3:0f brd ff:ff:ff:ff:ff:ff
11: tap100i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel master fwbr100i1 state UNKNOWN group default qlen 1000
    link/ether 72:06:d2:90:5b:06 brd ff:ff:ff:ff:ff:ff
12: fwbr100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 12:f4:74:8e:01:27 brd ff:ff:ff:ff:ff:ff
13: fwpr100p1@fwln100i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr1 state UP group default qlen 1000
    link/ether 22:c8:5e:1c:12:fc brd ff:ff:ff:ff:ff:ff
14: fwln100i1@fwpr100p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i1 state UP group default qlen 1000
    link/ether 12:f4:74:8e:01:27 brd ff:ff:ff:ff:ff:ff
15: tap100i2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel master fwbr100i2 state UNKNOWN group default qlen 1000
    link/ether ea:55:0d:c0:dd:63 brd ff:ff:ff:ff:ff:ff
16: fwbr100i2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 42:df:3d:11:ea:e1 brd ff:ff:ff:ff:ff:ff
17: fwpr100p2@fwln100i2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr2 state UP group default qlen 1000
    link/ether 0a:c5:e2:55:9c:00 brd ff:ff:ff:ff:ff:ff
18: fwln100i2@fwpr100p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i2 state UP group default qlen 1000
    link/ether 42:df:3d:11:ea:e1 brd ff:ff:ff:ff:ff:ff
root@pve1:~#
    link/ether ea:55:0d:c0:dd:63 brd ff:ff:ff:ff:ff:ff
16: fwbr100i2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 42:df:3d:11:ea:e1 brd ff:ff:ff:ff:ff:ff
17: fwpr100p2@fwln100i2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr2 state UP group default qlen 1000ult qlen 1000
    link/ether 0a:c5:e2:55:9c:00 brd ff:ff:ff:ff:ff:ff
18: fwln100i2@fwpr100p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i2 state UP group default qlen 1000default qlen 1000
    link/ether 42:df:3d:11:ea:e1 brd ff:ff:ff:ff:ff:ff
root@pve1:~#
17: fwpr100p2@fwln100i2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr2 state UP group default qlen 1000ult qlen 1000
    link/ether 0a:c5:e2:55:9c:00 brd ff:ff:ff:ff:ff:ff
18: fwln100i2@fwpr100p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr100i2 state UP group default qlen 1000default qlen 1000
    link/ether 42:df:3d:11:ea:e1 brd ff:ff:ff:ff:ff:ff
root@pve1:~#

I can telnet from my machine (um890) to ports 8006 and 22:

Code Select Expand

telnet 192.168.2.2 8006
Trying 192.168.2.2...
Connected to 192.168.2.2.
Escape character is '^]'.
^[
HTTP/1.0 400 bad request
Cache-Control: max-age=0
Connection: close
Date: Wed, 03 Sep 2025 13:56:20 GMT
Pragma: no-cache
Server: pve-api-daemon/3.0
Content-Length: 11
Expires: Wed, 03 Sep 2025 13:56:20 GMT

bad requestConnection closed by foreign host.

# [2025-09-03 23:56] maxg@um890 ~ $
telnet 192.168.2.2 22
Trying 192.168.2.2...
Connected to 192.168.2.2.
Escape character is '^]'.
SSH-2.0-OpenSSH_10.0p2 Debian-7
^[
Invalid SSH identification string.
Connection closed by foreign host.


What seems right to me, the Proxmox cannot ping the Google DNS, while OPNsense can. It can nslookup though.
I added a 192.168.2.2 to any rule in LAN assuming the Proxmox host on 192.168.2.2) would be able to ping, but it can't.

Code Select Expand

root@pve1:~# nslookup 8.8.8.8
8.8.8.8.in-addr.arpa    name = dns.google.

Authoritative answers can be found from:

root@pve1:~# ping -c3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2059ms

root@pve1:~# ss -tuln | grep :8006
tcp  LISTEN 0      4096              *:8006            *:* 
root@pve1:~# iptables -L -v -n
Chain INPUT (policy ACCEPT 49678 packets, 21M bytes)
pkts bytes target    prot opt in    out    source              destination       

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target    prot opt in    out    source              destination       

Chain OUTPUT (policy ACCEPT 35490 packets, 23M bytes)
pkts bytes target    prot opt in    out    source              destination       


I would kindly invite some help, hints. pointers on what I am missing or where to go. I am happy to provide further information to aid trouble-shooting, but there is lots of it (and I don't know where to start).