"Recent posts
#81
25.7, 25.10 Series / Re: IPv4 ONLY Firewall Setup w...
Last post by Dude7 - January 26, 2026, 10:56:39 PM@meyergru
Thank you for your response. The details in it really helped, even though I still have not successfully been able to get OPNsense completely functional.
I am going to take the time to post a few errors that I found on my part, and validate why taking the step that you guided to do in eliminating Proxmox as a variable. That helped me to find serious hardware issues I was unaware of until I went with a bm (bare metal / no other OS but OPNSense on the hardware) install.
I hope this helps in paying it forward with someone else having similar symptoms/issues.
First, at some point in the dozens, and dozens of rebuild attempts, I had created Layer-2 network conflicts by not creating networks that were on the same subnet.
Please correct me if I'm wrong @meyergru about any of this.
For those reading this in the future that may have similar problems. You CANNOT have different IP ranges with different subnets (i.e 192.168.x.x, and 172.200.x.x, and 10.10.x.x, etc.). Just because everything has the same CIDR declaration (i.e. /24, /16, etc.) does NOT mean that they are not going to conflict, or more importantly are IN THE SAME RANGE.
I had created my primary LAN management port IP as 192.168.100.1/24
At some point in the troubleshooting I had CHANGED all of my other optional LANs to 10.10.X.X while leaving my primary as 192.168.100.x
That was the mistake that I had made which was creating the Layer-2 network errors.
However for me, that still did not get things working.
Before I wiped and started completely clean with a bm install, I checked VLAN aware status on Proxmox for all of the Linux Bridges. Everything was fine there.
From every sign, and from what I could derive, Proxmox was working fine. That was not the issue though.
When I wiped the hardware and installed OPNsense natively on the hardware, all interfaces came up correctly and I assigned the interfaces as follows:
LAN1-Management- 192.168.100.1/24
WAN- DHCP (No static IP assigned) [It will acquire it from my ISP upstream]
LAN2- 192.168.115.1/24
LAN3- 192.168.116.1/24
LAN4- 192.168.117.1/24
LAN5- 192.168.118.1/24
No VLAN's at this point. I don't want to complicate things until I get the DHCP server issue resolved.
What I found though is something that may help others. When starting up the anti-lockout rules will allow the traffic to the GUI interface on any port. That is both good and bad. Bad, if you assume that all is well, and that you are connected physically to the right port. That was the mistake I was having.
The LAN interface that I assumed was the right physical NIC port once again works with DHCP no problems.
My clue was that the WAN was NOT acquiring an IP address upstream.
That is when I used an IP scanner (Angry IP, LAN Scan, etc.). I manually assigned an IP address to my client machine that's networked, and of which I am using to access OPNsense. I am again eliminating potential issues by just a single wire from the OPNsense box, directly to the client hardware NIC. No other hardware in between.
I physically unplugged the cable, and started plugging into other ports. At the same time I was manually changing the static IP address to be in the range, but not the same address (i.e. 192.168.115.10) as the gateway address for that interface (i.e. 192.168.115.1).
What I found in my hardware was that the actual NIC assignment on my OPNsense box is completely opposite than what it is labeled on the front of the case by the manufacturer. It was sequentially inverted, meaning instead of ports labeled / numbered left to right, it was right to left.
SIDE NOTE- I have heard of some hardware having ports that are randomly numbered and not sequential in their hardware placement.
LESSON LEARNED- Check and VALIDATE your physical network ports BEFORE YOU START TROUBLESHOOTING ANYTHING ELSE! Don't believe the labels!
So Proxmox was creating Linux Bridges correctly all along. The problem was that I was plugging into the wrong ports, all while assuming I was plugged into and working on the correct ones.
Once I was able to determine this problem, I was able to go back and use the same IP sniffing program to see if it would find all of the host static IP addresses for the interfaces as they are assigned in OPNsense. All of them were found where they should be, and with what network IP addresses they should have.
The problem that I have now, is the same original problem that started this forum post thread. I cannot get the DHCP server to provide addresses for each interface.
At present, I have completely disabled the firewall in the Firewall > Settings tab. I will re-enable, and work on rules once I can get a basic DHCP server working on each LAN.
I hope taking the time to post this information helps others that may run into the same problems.
Also, I will likely go back to a Proxmox setup later, but not until I get a functional setup of OPNsense on bm working properly.
Thank you @meyergru for bringing up the Layer-2, and the bm troubleshooting steps. I had worked on this until my eyes were crossing and completely had not thought about the possibility of what I found, and the errors I had created.
@meyergru What would you advise at this point with regards to next steps in resolving the DHCP server issues that I'm am seeing consistently on all optional LAN ports?
FYI, I have made sure in DNSmasq that all interfaces are checked/selected instead of unchecked which leaves the drop-down menu to say "All Interfaces."
Thanks in advance for the response.
Thank you for your response. The details in it really helped, even though I still have not successfully been able to get OPNsense completely functional.
I am going to take the time to post a few errors that I found on my part, and validate why taking the step that you guided to do in eliminating Proxmox as a variable. That helped me to find serious hardware issues I was unaware of until I went with a bm (bare metal / no other OS but OPNSense on the hardware) install.
I hope this helps in paying it forward with someone else having similar symptoms/issues.
First, at some point in the dozens, and dozens of rebuild attempts, I had created Layer-2 network conflicts by not creating networks that were on the same subnet.
Please correct me if I'm wrong @meyergru about any of this.
For those reading this in the future that may have similar problems. You CANNOT have different IP ranges with different subnets (i.e 192.168.x.x, and 172.200.x.x, and 10.10.x.x, etc.). Just because everything has the same CIDR declaration (i.e. /24, /16, etc.) does NOT mean that they are not going to conflict, or more importantly are IN THE SAME RANGE.
I had created my primary LAN management port IP as 192.168.100.1/24
At some point in the troubleshooting I had CHANGED all of my other optional LANs to 10.10.X.X while leaving my primary as 192.168.100.x
That was the mistake that I had made which was creating the Layer-2 network errors.
However for me, that still did not get things working.
Before I wiped and started completely clean with a bm install, I checked VLAN aware status on Proxmox for all of the Linux Bridges. Everything was fine there.
From every sign, and from what I could derive, Proxmox was working fine. That was not the issue though.
When I wiped the hardware and installed OPNsense natively on the hardware, all interfaces came up correctly and I assigned the interfaces as follows:
LAN1-Management- 192.168.100.1/24
WAN- DHCP (No static IP assigned) [It will acquire it from my ISP upstream]
LAN2- 192.168.115.1/24
LAN3- 192.168.116.1/24
LAN4- 192.168.117.1/24
LAN5- 192.168.118.1/24
No VLAN's at this point. I don't want to complicate things until I get the DHCP server issue resolved.
What I found though is something that may help others. When starting up the anti-lockout rules will allow the traffic to the GUI interface on any port. That is both good and bad. Bad, if you assume that all is well, and that you are connected physically to the right port. That was the mistake I was having.
The LAN interface that I assumed was the right physical NIC port once again works with DHCP no problems.
My clue was that the WAN was NOT acquiring an IP address upstream.
That is when I used an IP scanner (Angry IP, LAN Scan, etc.). I manually assigned an IP address to my client machine that's networked, and of which I am using to access OPNsense. I am again eliminating potential issues by just a single wire from the OPNsense box, directly to the client hardware NIC. No other hardware in between.
I physically unplugged the cable, and started plugging into other ports. At the same time I was manually changing the static IP address to be in the range, but not the same address (i.e. 192.168.115.10) as the gateway address for that interface (i.e. 192.168.115.1).
What I found in my hardware was that the actual NIC assignment on my OPNsense box is completely opposite than what it is labeled on the front of the case by the manufacturer. It was sequentially inverted, meaning instead of ports labeled / numbered left to right, it was right to left.
SIDE NOTE- I have heard of some hardware having ports that are randomly numbered and not sequential in their hardware placement.
LESSON LEARNED- Check and VALIDATE your physical network ports BEFORE YOU START TROUBLESHOOTING ANYTHING ELSE! Don't believe the labels!
So Proxmox was creating Linux Bridges correctly all along. The problem was that I was plugging into the wrong ports, all while assuming I was plugged into and working on the correct ones.
Once I was able to determine this problem, I was able to go back and use the same IP sniffing program to see if it would find all of the host static IP addresses for the interfaces as they are assigned in OPNsense. All of them were found where they should be, and with what network IP addresses they should have.
The problem that I have now, is the same original problem that started this forum post thread. I cannot get the DHCP server to provide addresses for each interface.
At present, I have completely disabled the firewall in the Firewall > Settings tab. I will re-enable, and work on rules once I can get a basic DHCP server working on each LAN.
I hope taking the time to post this information helps others that may run into the same problems.
Also, I will likely go back to a Proxmox setup later, but not until I get a functional setup of OPNsense on bm working properly.
Thank you @meyergru for bringing up the Layer-2, and the bm troubleshooting steps. I had worked on this until my eyes were crossing and completely had not thought about the possibility of what I found, and the errors I had created.
@meyergru What would you advise at this point with regards to next steps in resolving the DHCP server issues that I'm am seeing consistently on all optional LAN ports?
FYI, I have made sure in DNSmasq that all interfaces are checked/selected instead of unchecked which leaves the drop-down menu to say "All Interfaces."
Thanks in advance for the response.
#82
General Discussion / Re: GeoIP not working
Last post by buckey96 - January 26, 2026, 10:50:57 PMThat makes sense, but I don't have the ability to select the source.
#83
General Discussion / Re: How to set limited bandwif...
Last post by meyergru - January 26, 2026, 10:30:22 PMIsn't that exactly what the documentation shows? https://docs.opnsense.org/manual/how-tos/shaper_limit_per_user.html
#84
Hardware and Performance / Re: SFP+ to RJ45 slow WAN spe...
Last post by pfry - January 26, 2026, 10:16:11 PMQuote from: Seimus on January 26, 2026, 08:31:00 PM[...]SFPs have often a MON[...]
Grr. Good point:
Code Select
root@fw:/home/user # ifconfig -v ixl3
ixl3: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: x710p3 (opt4)
options=4800028<VLAN_MTU,JUMBO_MTU,HWSTATS,MEXTPG>
ether 3c:fd:fe:e7:2d:8b
media: Ethernet autoselect (10Gbase-SR <full-duplex>)
status: active
nd6 options=9<PERFORMNUD,IFDISABLED>
drivername: ixl3
plugged: SFP/SFP+/SFP28 10G Base-SR (LC)
vendor: Intel Corp PN: AFBR-709DMZ-IN3 SN: AA202830LM3 DATE: 2020-07-11
module temperature: 27.90 C voltage: 3.35 Volts
lane 1: RX power: 0.51 mW (-2.92 dBm) TX bias: 5.46 mA
root@fw:/home/user # #85
General Discussion / How to set limited bandwifth f...
Last post by Arno - January 26, 2026, 10:10:46 PMHi,
Sometimes a computer on my LAN uses all the available bandwidth.
How do I setup Shaper?
Goal: Max bandwidth as default accept for some computers.
Now I have: Four Pipes: Down/Up for Max and Limited.
No queues.
Four rules: Down/Up for Computer to limit first (Limited pipes) followed by rules for LAN (Max pipes)
At the Status page there are stats for the max pipes but none for the limited pipes.
Sometimes a computer on my LAN uses all the available bandwidth.
How do I setup Shaper?
Goal: Max bandwidth as default accept for some computers.
Now I have: Four Pipes: Down/Up for Max and Limited.
No queues.
Four rules: Down/Up for Computer to limit first (Limited pipes) followed by rules for LAN (Max pipes)
At the Status page there are stats for the max pipes but none for the limited pipes.
#86
26.1 Series / Re: 26.1.rc1 -> 26.1 rc2 ........
Last post by Cljackhammer - January 26, 2026, 09:56:41 PMI upgraded as well and it went smoothly. Additionally, the latest version of hostwatch is a massive improvement in terms of disk writes. I can leave it enabled now.
#87
25.7, 25.10 Series / Re: New site PPPoE PMTU woes
Last post by ToasterPC - January 26, 2026, 09:42:11 PMQuote from: meyergru on January 24, 2026, 10:22:34 PMIf reducing the MTU size on your Windows client does not fix the problem, them maybe the MTU size is not the problem after all?Honestly that's quite likely, though I'm still unsure on how to test for such a scenario.
Quote from: meyergru on January 24, 2026, 10:22:34 PMDid you try the ping to your OpnSense instance itself, too?Yes, and it seems getting to the firewall itself has no issues with employing packets way above the interface MTU
Code Select
Pinging 10.10.1.1 with 10000 bytes of data:
Reply from 10.10.1.1: bytes=10000 time=2ms TTL=64
Reply from 10.10.1.1: bytes=10000 time=32ms TTL=64
Reply from 10.10.1.1: bytes=10000 time=14ms TTL=64
Reply from 10.10.1.1: bytes=10000 time=2ms TTL=64
Reply from 10.10.1.1: bytes=10000 time=2ms TTL=64
Ping statistics for 10.10.1.1:
Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 32ms, Average = 10msQuote from: meyergru on January 24, 2026, 10:22:34 PMFor modern Windows versions, I think they automagically set the MTU size - IDK how they do that exactly, however. I do not have the problem, as both my WAN and LAN MTUs are 1500 bytes.Tbh neither do I, but I do know how to set it manually if it's ever needed (thanks to this GitHub Gist):
From an Administrative Command Prompt/PowerShell session, use the following command to list the system's available interfaces and their current MTU values:
Code Select
netsh interface ipv4 show subinterfacesWhich in my case outputs the following:
Code Select
MTU MediaSenseState Bytes In Bytes Out Interface
---------- --------------- ------------ ------------ -------------
4294967295 1 0 169774 Loopback Pseudo-Interface 1
1500 5 0 0 Onboard GbE
1464 1 1872595478 40841253 WiFi
1500 5 0 0 Local Area Connection* 1
1500 5 0 0 USB 2.5GbE
1280 1 0 17580 Tailscale
1500 5 0 0 Local Area Connection* 2
65535 5 0 0 Local Area Connection
1500 1 0 120046 vEthernet (Default Switch)
1500 1 189514 974851 vEthernet (WSL (Hyper-V firewall))
1500 1 1968 151879 VMware Network Adapter VMnet1
1500 1 1968 150820 VMware Network Adapter VMnet8
1500 5 0 0 Bluetooth Network ConnectionAs such, after identifying the interface needing the change, the MTU can be set by using this other command:
Code Select
netsh interface ipv4 set subinterface "WiFi" mtu=1464If everything went as expected, the output will be:
Code Select
Ok. #88
Tutorials and FAQs / Re: HOWTO - Redirect all DNS R...
Last post by Javier® - January 26, 2026, 09:36:20 PMHi, the best option for redirecting DNS is to use rdr on the same interface.
rdr pass in quick on $if_lan proto { udp tcp } from any to any port domain -> lo0 port domain
I use it on OpenBSD
pass in quick on $if_lan proto { udp tcp } from any to any port domain rdr-to lo0 port domain
rdr pass in quick on $if_lan proto { udp tcp } from any to any port domain -> lo0 port domain
I use it on OpenBSD
pass in quick on $if_lan proto { udp tcp } from any to any port domain rdr-to lo0 port domain
#89
High availability / Re: CARP OS-FRR timeout after ...
Last post by franco - January 26, 2026, 09:03:56 PMWasn't it this one? https://github.com/opnsense/plugins/commit/2cc2215bb
If so we're hotfixing this for the last update of 25.7.11_x shortly after 26.1 is out this week.
Cheers,
Franco
If so we're hotfixing this for the last update of 25.7.11_x shortly after 26.1 is out this week.
Cheers,
Franco
#90
26.1 Series / Re: 26.1.rc1 -> 26.1 rc2 ........
Last post by PoMpIs - January 26, 2026, 09:02:33 PMI've also upgraded from RC1 to RC2 and everything works perfectly. I've ported the old rules to the new rules.
I also really like the categories in the new rules. 👌
Cheers 😊
I also really like the categories in the new rules. 👌
Cheers 😊
