Recent posts

#1
General Discussion / Re: OPNsense on Proxmox > Can'...
Last post by quqide - Today at 09:36:30 AM
Thanks, I took a look at your guide as well whilst troubleshooting, whats where I got mcsnoop from. I hope I didn't misinterpret your guide.

I am doing bridging with the LAN and WAN Interface I am using virtio for the VM, so in OPNsense I have my two vtnet adapters which I assigned.
So I should not be using PCI passthrough.
#2
General Discussion / Re: OPNsense on Proxmox > Can'...
Last post by meyergru - Today at 09:25:33 AM
Two basic things:

1. In order for passthru to work, you must have exclusive access in the VM, so configuring the NIC on the PVE host is a no-go. There are lots of prerequisites to do this. It cannot be successful if you do not see the NIC in the OpnSense VM.

2. This worked under Proxmox with a virtio adapter? Then Linux is fine handling your Realtek device. How do I know it is Realtek? Because your MAC OUI tells me so. See this, point 6.

I generally do not recommend using passthru unless strictly neccessary, see: https://forum.opnsense.org/index.php?topic=44159.0. bridge-mcsnoop is explained there, too. And as a general rule: Do not use AI or YT videos to learn about OpnSense. There is plenty of ggod documentation and also the tutorial section of this forum.
#3
General Discussion / OPNsense on Proxmox > Can't ge...
Last post by quqide - Today at 09:09:39 AM
Hi all,

I recently decided to migrate from a UniFi Dream Machine to OPNsense running as a VM on Proxmox.

OPNsense itself is working fine, and I've already moved several VMs onto the new OPNsense LAN bridge in Proxmox. Those VMs receive IP addresses via DHCP without any issues.

However, I'm running into a problem when I try to connect a physical device directly to the NIC that is attached to the OPNsense LAN bridge:
  • DHCP does not work on the physical NIC
  • If I configure a static IP on the physical device, I can reach OPNsense and the rest of the network just fine
  • This makes it appear to be a DHCP-only issue

My setup in short with 4 NICs total
  • SFP+ #1 and #2: bonded and used for VMs (still connected to UniFi)
  • RJ45 #1: OPNsense WAN (currently connected to an unused VLAN on UniFi; when connected directly to my ISP WAN, DHCP works fine)
  • RJ45 #2: OPNsense LAN
  • 10.27.10.0/24 old Subnet (UniFi)
  • 10.27.11.0/24 (New LAN Subnet; currently Proxmox has no IP assigned to the vmbr but I can reach it via static IP on the Client)
VMs connected to the corresponding vmbr receive DHCP leases correctly
Physical devices connected to this NIC do not receive DHCP leases

Proxmox Nework config:
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

auto enp87s0
iface enp87s0 inet manual

auto enp90s0
iface enp90s0 inet manual

auto enp2s0f0np0
iface enp2s0f0np0 inet manual

auto enp2s0f1np1
iface enp2s0f1np1 inet manual

iface wlp91s0 inet manual

auto bond0
iface bond0 inet manual
bond-slaves enp2s0f0np0 enp2s0f1np1
bond-miimon 100
bond-mode balance-rr

auto vmbr1
iface vmbr1 inet static
address 10.27.10.20/24
gateway 10.27.10.1
bridge-ports bond0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
bridge-mcsnoop 0
#VMs

auto vmbr3
iface vmbr3 inet manual
bridge-ports enp90s0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
bridge-mcsnoop 0
#OPNsense LAN

auto vmbr0
iface vmbr0 inet manual
bridge-ports enp87s0
bridge-stp off
bridge-fd 0
bridge-mcsnoop 0
#OPNsense WAN

source /etc/network/interfaces.d/*

As DHCP works on VMs connected to the bridge I don't think it's a OPNsense configuration issue but a Proxmox NIC issue.
In the OPNsense log I can see it handing out DHCP offers. On Proxmox the Firewall on those to bridges is off.

When doing a TCP dump on the NIC on Proxmox:
root@proxmox:~# tcpdump -i enp90s0 -n port 67 or 68
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp90s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:05:39.455550 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:e0:4c:8f:b7:91, length 300
09:05:42.742892 IP 10.27.11.1.67 > 10.27.11.133.68: BOOTP/DHCP, Reply, length 306
09:05:44.211604 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:e0:4c:8f:b7:91, length 300
09:05:44.212508 IP 10.27.11.1.67 > 10.27.11.133.68: BOOTP/DHCP, Reply, length 306
09:05:52.962341 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:e0:4c:8f:b7:91, length 300
09:05:52.963488 IP 10.27.11.1.67 > 10.27.11.133.68: BOOTP/DHCP, Reply, length 306
09:06:09.456204 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:e0:4c:8f:b7:91, length 300
09:06:09.457166 IP 10.27.11.1.67 > 10.27.11.133.68: BOOTP/DHCP, Reply, length 306
09:06:41.201306 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:e0:4c:8f:b7:91, length 300
09:06:44.495939 IP 10.27.11.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 306
09:06:45.700361 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:e0:4c:8f:b7:91, length 300
09:06:45.701570 IP 10.27.11.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 306
09:06:53.944040 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:e0:4c:8f:b7:91, length 300
09:06:53.944912 IP 10.27.11.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 306
09:07:09.453246 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:e0:4c:8f:b7:91, length 300
09:07:09.454095 IP 10.27.11.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 306

I tried with Google and ChatGPT but can't get it to work. Current thinking is that something gets blocked by Proxmox - thats why I added bridge-mcsnoop 0 to the config - but nothing helps.
I tried multiple different Clients. Also, on a Windows Client, it succesfully set the DHCP local domain name like home.arpa but nothing else.

Thank you!
#4
25.7, 25.10 Series / Re: New site PPPoE PMTU woes
Last post by meyergru - Today at 09:06:28 AM
I have never seen any such big MTUs. With 1.1.1.1, I did not get any conclusive results. Try 8.8.8.8.
#5
German - Deutsch / Re: MTU bei PPPoe | Deutsche G...
Last post by engels0n - Today at 09:02:14 AM
Moin zusammen,
also das Setzen des MSS Wertes 1492 bei WAN scheint tatsächlich Erfolg zu bringen.
Seit Freitag hatte ich nicht einen gedroppten Seitenaufruf.

Nach etwas weiterem Googlen habe ich dann noch folgenden GitHUB Eintrag gefunden, der genau auf das Thema eingeht:
https://github.com/opnsense/core/issues/9398

Also scheint die Berechnung des MSS Wertes bei der Konstellation PPPOE + MTU fehlerhaft zu sein, wenn MTU = 1492
Wenn ich keinen MSS Wert eintrage, bekomme ich den Wert von 1460 angezeigt, was natürlich falsch ist.
Mit Setzen des Wertes auf 1492 analog der MTU ist der Wert korrekt auf 1452.

Ich bedanke mich und wünsche noch einen schönen Sonntag :)

LG
#6
25.7, 25.10 Series / Re: Hostwatch - high disk writ...
Last post by nicholaswkc - Today at 07:53:02 AM
Quote from: Patrick M. Hausen on January 17, 2026, 03:59:17 PMInterfaces: Neighbors: Automatic Discovery
Thanks.
#7
25.7, 25.10 Series / Re: clarification of snapshots
Last post by passeri - Today at 03:24:56 AM
Quote from: tessus on Today at 02:07:17 AMSo how can I rollback or switch to a point where the new firmware was not installed, if the operations are persisted
This is, in terms of my explanation, a configuration change. It is not part of the snapshot, so you can still roll back to the prior configuration.
#8
General Discussion / Re: Development / Community / ...
Last post by pfry - Today at 03:09:49 AM
Quote from: Maurice on January 17, 2026, 08:37:15 PM[...]From what I see on GitHub and the forum and from my own experience, hostwatch is still in the development phase.[...]

Seeing "This release brings the new host discovery service..." in the release announcement I upgraded, then immediately hunted down the service and killed it, as I did not see a need for it. (After looking at its output, of course - you never can tell, it could be exciting.) I suppose that puts me in the
QuoteDevelopment = alpha, Community = beta, Business = stable
group, not that I would consider any software to be "stable".

#9
Well I solved the issue. It believe OPNsense was not the issue.
Flow Control on the Aruba switch wasn't working even though it was enabled. I was able to do some more testing with IPerf and found that when sending data from a higher link.
Did testing between 10gb links and 1 gig links and found the same 300mbps when sending data from the 10gb links to 1gb but fine in the opposite direction.

I think there was a glitch in the Aruba Switch (3.3.2) that seemed to not apply flow control. I finally got it to work after testing Aruba shaping setting and when removed the shaping settings it seems to work just fine. Speeds on 1gb links are good and also good on 2.5 and 10gb links.
#10
25.7, 25.10 Series / Re: clarification of snapshots
Last post by tessus - Today at 02:35:29 AM
Quote from: OPNenthu on Today at 02:28:09 AMAfter you boot into the snapshot you activated manually, it will retain its name.  You can then delete the old 'default' and rename the current one as 'default' if you wish.

This is clear to me. Thanks. What I had issues with was that snapshots were not traditional snapshots I could rollback to multiple times.

Your previous post was partly responsible for my understanding of OPNsense snapshots. It finally made click. Thank you!