"Recent posts
#81
Tutorials and FAQs / Re: OPNsense + PROXMOX + VLANs...
Last post by viragomann - Today at 09:19:56 AMIf you don't have a VLAN-capable switch to terminate the VLANs, but connect a PC directly to Proxmox, you have to configure the proper VLAN (2) on it's network interface to access OPNsense.
#82
25.7, 25.10 Series / DNS lookups by opnsense server
Last post by dunxd - Today at 09:04:42 AMI use pihole as the DNS server on my network, with all clients told to use it via DHCP from DNSmasq running on my OPNsense box.
Daily I get warnings about rate limiting being applied to my OPNsense router's IP address, and OPNsense is making over 50% of DNS requests.
I have configured OPNsense to use only upstream DNS servers on the Settings > General page, and again for Zenarmor's DNS enrichment setting - so I would not expect the OPNsense server to be doing any DNS lookups via pihole at all.
Is there somewhere else that OPNsense might be configured to do DNS lookups?
Daily I get warnings about rate limiting being applied to my OPNsense router's IP address, and OPNsense is making over 50% of DNS requests.
I have configured OPNsense to use only upstream DNS servers on the Settings > General page, and again for Zenarmor's DNS enrichment setting - so I would not expect the OPNsense server to be doing any DNS lookups via pihole at all.
Is there somewhere else that OPNsense might be configured to do DNS lookups?
#83
High availability / Re: HAProxy not working / star...
Last post by Monviech (Cedrik) - Today at 08:29:40 AMIf you have cloudflare try to use caddy instead its way easier to setup:
https://docs.opnsense.org/manual/how-tos/caddy.html
https://docs.opnsense.org/manual/how-tos/caddy.html
#84
General Discussion / Re: Can I inststall smokeping ...
Last post by franco - Today at 08:24:32 AMIf you can grab a package from FreeBSD that would be your best bet. I don't know why it breaks during build, but it could also mean the FreeBSD package is no longer available either.
Cheers,
Franco
Cheers,
Franco
#85
High availability / HAProxy not working / starting...
Last post by rohitashs - Today at 08:17:11 AMI have Opnsense running as my home router on a ESXi VM. I recently update to the latest version 25.7.9_7. I'm trying to setup HAProxy (for the first time) to expose some self-hosted services (all still in planning stage). I'm relatively new to home labs and self hosting so learning along the way. I have setup a domain Cloudflare and have got the ddns working in Opnsense I also have got a wildcard certificate for my domain from LetsEncrypt working. Next step is to install the HAProxy plugin and do a test with one dummy self hosted web server. I can successfully install the HAProxy Plugin and then see it under the services menu in Opnsense. When i try to go to the settings however I get "There are pending configuration changes that must be applied in order for them to take effect. To review them visit the Config Diff page." on the Settings tab (and on all the other tabs un Settings). There is a button to Apply and to Test Syntax. Test Syntax says there are no errors. When I "Apply" it does nothing and I keep seeing the same thing. I cannot see any of the actual settings on any of the tabs - just the documentation. I dont see anything in the System Logs for anything related to HAProxy and the HAProxy log is empty. When I go to ConfigDiff i see these 3 lines at the top:
--- /usr/local/etc/haproxy.conf 1969-12-31 16:00:00.000000000 -0800 (in red)
+++ /usr/local/etc/haproxy.conf.staging 2025-12-16 23:11:58.352843000 -0800 (in green)
@@ -0,0 +1,48 @@ (in blue)
Can someone please guide me in the right direction for troubleshooting? I've been searching the internet for almost a day now with no progress yet. Thanks in advance!
--- /usr/local/etc/haproxy.conf 1969-12-31 16:00:00.000000000 -0800 (in red)
+++ /usr/local/etc/haproxy.conf.staging 2025-12-16 23:11:58.352843000 -0800 (in green)
@@ -0,0 +1,48 @@ (in blue)
Can someone please guide me in the right direction for troubleshooting? I've been searching the internet for almost a day now with no progress yet. Thanks in advance!
#86
25.7, 25.10 Series / Re: Issues keeping vlan after ...
Last post by megabox - Today at 07:52:05 AMI may have fixed this:
Reload everything from usb boot as noted, to clear messy existing settings.
Reboot and log in as root in GUI.
usb/rj45 (ue0) as lan
wired nic (re0) as wan
update re0 to use ISP router MAC
enable/set to prevent removal (ensures USB interface stays at LAN, otherwise will swap to WAN if this isn't set)
different steps this time:
add VLAN on re0 (Interfaces->Devices->VLAN):
- device: vlan0.10
- parent: re0
- VLAN tag: 10
Interfaces: [WAN_VLAN10]
- enable
- prevent removal
- IPV4 DHCP
- mac: same as re0
-> save/apply
check WAN_VLAN10 gets public IP 202.* on opnsense box (yes)
check ping to 8.8.8.8 works on opnsense box (yes)
check ping to 8.8.8.8 works on lan connected laptop (yes)
-> reboot
changes stick (yes)
same checks (all good)
Looks like this is the solution - making the changes in the gui vs on the opnsense console
---
I'd be interested to hear any commentary on if this is a good solution or if there are other options?
Reload everything from usb boot as noted, to clear messy existing settings.
Reboot and log in as root in GUI.
usb/rj45 (ue0) as lan
wired nic (re0) as wan
update re0 to use ISP router MAC
enable/set to prevent removal (ensures USB interface stays at LAN, otherwise will swap to WAN if this isn't set)
different steps this time:
add VLAN on re0 (Interfaces->Devices->VLAN):
- device: vlan0.10
- parent: re0
- VLAN tag: 10
Interfaces: [WAN_VLAN10]
- enable
- prevent removal
- IPV4 DHCP
- mac: same as re0
-> save/apply
check WAN_VLAN10 gets public IP 202.* on opnsense box (yes)
check ping to 8.8.8.8 works on opnsense box (yes)
check ping to 8.8.8.8 works on lan connected laptop (yes)
-> reboot
changes stick (yes)
same checks (all good)
Looks like this is the solution - making the changes in the gui vs on the opnsense console
---
I'd be interested to hear any commentary on if this is a good solution or if there are other options?
#87
Web Proxy Filtering and Caching / Re: Squid Web Proxy Error (1)
Last post by Zeehan - Today at 05:59:31 AMThe Error 1 you see while applying policies in OPNsense with os-opnproxy is not caused by Redis or your policy logic. The issue happens because the os-opnproxy package triggers a Squid reload at the wrong time.
Here's what happens: policy entries are first written into the Redis database, and immediately after that the service script runs squid reload. When this happens together with OPNsense GUI activity, Squid can panic. At some point, the Squid binary cannot handle Redis writes, GUI operations, and a reload all at the same time, resulting in Error 1.
The fix I use is to modify the service script. Edit this file:
/usr/local/opnsense/service/conf/actions.d/actions_opnproxy.conf
Inside you'll see a line like:
/usr/local/opnsense/scripts/OPNProxy/policies_to_redis_proto.py | redis-cli --pipe && squid reload
Delete the "&& squid reload" part, save the file, then apply the policies again. If Error 1 still persists, restart OPNsense once.
If you use network-based user authentication only, the default Squid helper can only block non-SSL traffic. HTTPS traffic will still pass unless you use SSL inspection, which we typically don't want. The helper script is here:
/usr/local/opnsense/scripts/OPNProxy/squid_acl_helper.py
I have a modified version that can block SSL traffic when no allow policy exists. It's available here:
https://pastebin.com/cnecSZ7y
I am also working on a PySide6 GUI that connects to Redis and lets you manipulate policies and rules. It is still a prototype, works for small datasets, and entries may disappear after an OPNsense reboot. The GUI script is here:
https://pastebin.com/Nwr8A8Uq
If you plan to use the GUI, you must uncheck Redis protected mode in OPNsense. I tested this from Windows 11 connecting to Redis on OPNsense. You can use WinSCP to edit or replace files easily.
One experimental solution: you can remove os-opnproxy, keep Squid, place the modified helper manually, and create Redis entries using the correct JSON structure and order. In theory, Redis may not reset after reboot without os-opnproxy, but this is not fully tested.
Please note again that the GUI is still in prototype stage and cannot handle very large Redis datasets.
Here's what happens: policy entries are first written into the Redis database, and immediately after that the service script runs squid reload. When this happens together with OPNsense GUI activity, Squid can panic. At some point, the Squid binary cannot handle Redis writes, GUI operations, and a reload all at the same time, resulting in Error 1.
The fix I use is to modify the service script. Edit this file:
/usr/local/opnsense/service/conf/actions.d/actions_opnproxy.conf
Inside you'll see a line like:
/usr/local/opnsense/scripts/OPNProxy/policies_to_redis_proto.py | redis-cli --pipe && squid reload
Delete the "&& squid reload" part, save the file, then apply the policies again. If Error 1 still persists, restart OPNsense once.
If you use network-based user authentication only, the default Squid helper can only block non-SSL traffic. HTTPS traffic will still pass unless you use SSL inspection, which we typically don't want. The helper script is here:
/usr/local/opnsense/scripts/OPNProxy/squid_acl_helper.py
I have a modified version that can block SSL traffic when no allow policy exists. It's available here:
https://pastebin.com/cnecSZ7y
I am also working on a PySide6 GUI that connects to Redis and lets you manipulate policies and rules. It is still a prototype, works for small datasets, and entries may disappear after an OPNsense reboot. The GUI script is here:
https://pastebin.com/Nwr8A8Uq
If you plan to use the GUI, you must uncheck Redis protected mode in OPNsense. I tested this from Windows 11 connecting to Redis on OPNsense. You can use WinSCP to edit or replace files easily.
One experimental solution: you can remove os-opnproxy, keep Squid, place the modified helper manually, and create Redis entries using the correct JSON structure and order. In theory, Redis may not reset after reboot without os-opnproxy, but this is not fully tested.
Please note again that the GUI is still in prototype stage and cannot handle very large Redis datasets.
#88
25.7, 25.10 Series / Issues keeping vlan after rebo...
Last post by megabox - Today at 04:46:07 AMLooking for some guidance on persisting a tagging vlan interface after reboot, or if there is an alternative approach:
I'm setting a pc up with opnsense, using bootable usb drive as 'installer' user.
I first set up my usb/rj45 (ue0) as lan, and wired nic (re0) as wan.
Reboot and log in as root.
Connect 2nd pc directly to nic, it gets a 192.168.1.* IP, can ping opnsense box.
Prevent interface removal for LAN interface (ue0)
In opnsense console, run these commands:
ifconfig re0.10 create
ifconfig re0.10 vlan 10 vlandev re0
ifconfig re0.10 up
Back in GUI:
Assign WAN/re0 interface a specific mac address (same address as my ISP router)
Enable re0.10 interface with description WAN_VLAN10, set as DHCP, Prevent interface removal
Assign WAN_VLAN10/re0.10 interface same mac address as re0
Disable WAN/re0 interface
Wait a couple of minutes, re0.10 gains public IP
Can now ping eg. google/8.8.8.8 from opnsense and also from 2nd laptop. tracert shows opnsense box as first item so am assuming traffic is working as expected.
Everything looks good at this stage.
Now reboot opnsense.
After reboot
ue0/LAN interface OK, can ping opnsense box from 2nd laptop (lan seems OK)
all changes around re0/re0.10 missing and am unable to ping 8.8.8.8 and interface re0.10 is missing.
--
It looks like the changes made with ifconfig seem to work OK, but are not sticking post reboot.
At this stage, I'm not sure if there's something I'm missing or if I'm taking the wrong approach and there is a different method I should use to get vlan tagging working on re0 and/or re0.10?
I'm setting a pc up with opnsense, using bootable usb drive as 'installer' user.
I first set up my usb/rj45 (ue0) as lan, and wired nic (re0) as wan.
Reboot and log in as root.
Connect 2nd pc directly to nic, it gets a 192.168.1.* IP, can ping opnsense box.
Prevent interface removal for LAN interface (ue0)
In opnsense console, run these commands:
ifconfig re0.10 create
ifconfig re0.10 vlan 10 vlandev re0
ifconfig re0.10 up
Back in GUI:
Assign WAN/re0 interface a specific mac address (same address as my ISP router)
Enable re0.10 interface with description WAN_VLAN10, set as DHCP, Prevent interface removal
Assign WAN_VLAN10/re0.10 interface same mac address as re0
Disable WAN/re0 interface
Wait a couple of minutes, re0.10 gains public IP
Can now ping eg. google/8.8.8.8 from opnsense and also from 2nd laptop. tracert shows opnsense box as first item so am assuming traffic is working as expected.
Everything looks good at this stage.
Now reboot opnsense.
After reboot
ue0/LAN interface OK, can ping opnsense box from 2nd laptop (lan seems OK)
all changes around re0/re0.10 missing and am unable to ping 8.8.8.8 and interface re0.10 is missing.
--
It looks like the changes made with ifconfig seem to work OK, but are not sticking post reboot.
At this stage, I'm not sure if there's something I'm missing or if I'm taking the wrong approach and there is a different method I should use to get vlan tagging working on re0 and/or re0.10?
#89
25.7, 25.10 Series / *disregard...resolved* Sudden ...
Last post by DenverTech - Today at 04:09:12 AMResolved, see bottom.
I've been using Tailscale for a really really long time, originally with the port, then with the plugin. Worked without any issue, following the directions for rules. That was, until 2 nights ago. I rebooted my VPS, which is a remote tailscale node, as I've done many many times before without issue. I watched the tailscale connection come up...but nothing went through (more details below post-testing). Since then, I've been losing my mind, trying to figure out wtf changed and how to fix it. Please help!
I've reviewed other posts recently about Tailscale issues and the few that seem to match what I'm seeing were abandoned by the person asking, so no resolution was ever mentioned.
Testing info/details:
* Tailscale ACL is (and always has been), set up with ICMP allowed all:all for diagnosing scenarios just like this.
* From Opnsense to the VPS & VPS to Opnsense, pings work fine. I can ping either the host's actual IP or the tailscale IP of the device
* From the VPS side, I can ping anything on the Opnsense network. That tells me the all:all ACL is working as intended and the connection is good.
* From the Opnsense side, ONLY the Opnsense will ping things on the VPS side. It will not route anyone else to it.
* I _do_ have the rules that allow LAN to get to Tailscale. Those have not been changed in more than a year.
* I _do_ have the NAT Outbound rules for Tailscale. Those also have not been changed in more than a year.
* I'm not seeing any dropped/blocked packets in the Opnsense logs at all. Instead, I see the firewall rules passing the traffic without issue (ie, LAN to Tailscale), but the far tailscale devices never receive them. This seems like the NAT Outbound rule issue...but those rules are there and enabled. Unless something changed in how they're supposed to be configured, those are as they've been for a year+.
* Routes are being advertised and are approved on Tailscale (again, not changed in forever)
* The node has not expired.
LAN: 192.168.0.0/24
Opnsense: 192.168.0.1 & 172.0.0.1
Tailscale: 172.0.0.0/24
VPS Tailscale IP: 172.0.0.2
From Opnsense, I can ping 172.0.0.2.
From LAN, I can ping 172.0.0.1, but not 172.0.0.2
From VPS, I can ping 172.0.0.1 and all of 192.168.0.0/24
Anyone got any ideas, before I lose what's left of my hair over this surprise issue?
EDIT: Figured it out. A IoT device was apparently advertising routes that don't exist and killing a lot of the true advertised routes. Gotta go throw an IoT device against the wall a few times now.
I've been using Tailscale for a really really long time, originally with the port, then with the plugin. Worked without any issue, following the directions for rules. That was, until 2 nights ago. I rebooted my VPS, which is a remote tailscale node, as I've done many many times before without issue. I watched the tailscale connection come up...but nothing went through (more details below post-testing). Since then, I've been losing my mind, trying to figure out wtf changed and how to fix it. Please help!
I've reviewed other posts recently about Tailscale issues and the few that seem to match what I'm seeing were abandoned by the person asking, so no resolution was ever mentioned.
Testing info/details:
* Tailscale ACL is (and always has been), set up with ICMP allowed all:all for diagnosing scenarios just like this.
* From Opnsense to the VPS & VPS to Opnsense, pings work fine. I can ping either the host's actual IP or the tailscale IP of the device
* From the VPS side, I can ping anything on the Opnsense network. That tells me the all:all ACL is working as intended and the connection is good.
* From the Opnsense side, ONLY the Opnsense will ping things on the VPS side. It will not route anyone else to it.
* I _do_ have the rules that allow LAN to get to Tailscale. Those have not been changed in more than a year.
* I _do_ have the NAT Outbound rules for Tailscale. Those also have not been changed in more than a year.
* I'm not seeing any dropped/blocked packets in the Opnsense logs at all. Instead, I see the firewall rules passing the traffic without issue (ie, LAN to Tailscale), but the far tailscale devices never receive them. This seems like the NAT Outbound rule issue...but those rules are there and enabled. Unless something changed in how they're supposed to be configured, those are as they've been for a year+.
* Routes are being advertised and are approved on Tailscale (again, not changed in forever)
* The node has not expired.
LAN: 192.168.0.0/24
Opnsense: 192.168.0.1 & 172.0.0.1
Tailscale: 172.0.0.0/24
VPS Tailscale IP: 172.0.0.2
From Opnsense, I can ping 172.0.0.2.
From LAN, I can ping 172.0.0.1, but not 172.0.0.2
From VPS, I can ping 172.0.0.1 and all of 192.168.0.0/24
Anyone got any ideas, before I lose what's left of my hair over this surprise issue?
EDIT: Figured it out. A IoT device was apparently advertising routes that don't exist and killing a lot of the true advertised routes. Gotta go throw an IoT device against the wall a few times now.
#90
25.7, 25.10 Series / Re: Memory protection faults
Last post by teb - Today at 02:48:12 AMThanks guys! It's definitely RAM.. now I just have to find some that won't take 3 weeks to get to me, or cost me a kidney.
