After updating to OPNsense 25.1.5, I'm unable to reach the DMZ network.
Cannot communicate directly to the DMZ network from the LAN/WAN to a global address and cannot ping the DMZ network.
Internet connection from LAN is not a problem
https://github.com/opnsense/core/commits/25.1.4
https://github.com/opnsense/core/commits/25.1.5
I've been comparing commits, and I haven't been able to find a commit on my own that relates to this event.
- I've diff'd the routing table output from 25.1.4 and found no difference from 25.1.5.
- I have tried shutting down services that can be shut down, but communication is not restored.
- I logged into the router via SSH and tried pinging the DMZ address, but no response.
- I tried installing again from the ISO, but at the time of upgrade to 25.1.5, communication with the DMZ is lost.
- Pinging OPNsense from a server located in the DMZ still does not return a ping.
- 25.1.5 during startup There is a timing when the ping returns when the interface becomes active, but Configuring fireuall.... However, pings are not returned around the timing of "Configuring fireuall.
This issue did not occur in 25.1.4. Are there any known issues or changes that might cause this?
You don't share any details about your topology that could narrow the problem down.
Physical isolation? VLAN?
Hey there,
are you using the Captive Portal by any chance? I had an issue in 25.1.5 where it was running on all interfaces, which blocked access to everything else. Maybe that's related to what you're seeing.
> You don't share any details about your topology that could narrow the problem down. Physical isolation? VLAN?
OPNsense is running as a VM in XCP-ng and has a virtual NIC assigned to it
xcp.jpg
opnsense-ints.jpg
Firewall is configured as follows
pf-global.jpg
pf-office.jpg
Captive Portal is not used.
captive.jpg
I revert the patches in order and found that communication is not possible if the following commits are applied
https://github.com/opnsense/core/commit/e4f0e92dc5f3c9a521031ff91b1d2070d059383b
I referred to that commit and found the cause
It was caused by using a 10Gbp/s line and setting Shaper's default pipe to 10Gbp/s!
shaper10g.png
In my previous input, I used
https://github.com/opnsense/core/issues/5224
There was a section where I had entered 10000 Mbp/s because there was no limit on the number of Mbp/s, and I had to retype this as 40000 Mbp/s or 4 Gbp/s, or use the command revert
# opnsense-patch e4f0e92
Communication was restored with no problems.
> There was a section where I had entered 10000 Mbp/s because there was no limit on the number of Mbp/s, and I had to retype this as 40000 Mbp/s or 4 Gbp/s, or use the command revert
Validations were added to the GUI to prevent entries above 4Gbps a long time ago, perhaps this configuration was from before this validation was added, and now crashes due to the backend service change.
Before this patch the shaping was fully handled by IPFW, so if it broke there, traffic would likely still pass through pf. However, since pf now handles this and crashes on the pipe configuration it's reasonable to assume this would lock up traffic as well. However, since it's an incorrect configuration in both scenarios the right thing to do is to ditch the 10Gbps pipes.