"Recent posts
#21
25.1, 25.4 Series / Re: captive portal idletimeout...
Last post by Toon - Today at 11:33:46 AMIn this issue comment Stephan de Wit announced that he fixed this.
I've tested it with OPNsense-25.7.10 and can confirm that the idle time-out of the Captive Portal now works correctly for Wireguard.
Thanks guys!
I've tested it with OPNsense-25.7.10 and can confirm that the idle time-out of the Captive Portal now works correctly for Wireguard.
Thanks guys!
#22
General Discussion / Re: My pf ruleset causing clie...
Last post by OPNenthu - Today at 11:26:26 AMI was using the floating rule as a lazy shortcut to not have to change switch ports but now I see that it doesn't even work except in specific circumstances.
#23
Hardware and Performance / Re: Dec740 connected to a USW-...
Last post by patient0 - Today at 11:16:58 AMQuote from: DEC740airp414user on Today at 10:46:28 AMDo you mean wireguard groupEither work, the order is <interface group> first and then the <interface(s)>. If you have quick rules in the interface group that match, the interface rules are not evaluated.
Or the wireguard tunnel to external isp
Allow all or all This Firewall sound good but without seeing the rules I would know.
https://docs.opnsense.org/manual/firewall.html#processing-order
Quote2nd part of weirdness.
* patient0 has not idea here
#24
Hardware and Performance / Re: Dec740 connected to a USW-...
Last post by DEC740airp414user - Today at 10:46:28 AMQuote from: patient0 on Today at 07:23:41 AMQuote from: DEC740airp414user on December 27, 2025, 10:34:59 PMany device going over the wireguard tunnel can't access the router gui.What firewall rules have you created on the Wireguard interface?
Do you mean wireguard group
Or the wireguard tunnel to external isp
Group has the default rule still which I honestly don't remember being there on my old appliance I can boot it up to verify
The other is empty just like the old device. I imported the rules from the configuration file
I've gone in and made rules on each interface. I allowed all, didn't work. then I created allowed to destination *this firewall). that did not work either after cleaning states. I can not PING the appliance. how is that possible?
2nd part of weirdness. under System: Trust: Certificates. the webgui tis cert is there. but when you open it. and try to close it it says error missing CA key.
when I received the appliance I did a fresh install of business edition. is that error part of this, or is that normal?
#25
General Discussion / Re: My pf ruleset causing clie...
Last post by Patrick M. Hausen - Today at 10:30:30 AMYou can bind different services to different interfaces, of course. But if your management desktop and TN share a common network and you define "management" to be a different one to be accessed through a firewall, TN will send the replies through the common network bypassing the firewall, because that's how routing works.
A separate storage network for e.g. iSCSI assumes that all clients and the TN server share that network, so no asymmetric routing occurs. That of course is perfectly reasonable. Same for e.g. NFS for VMware.
But placing mangement in a separate network does not work unless the management station is in that same network. Just like with the storage examples.
And yes, with Proxmox (or ESXi) the host usually does not have IP addresses in those bridge/vSwitch networks used for VMs or containers. And you can do the same with TN.
Only services running on the host all share a single stack. Which never happens with Proxmox because Proxmox does not offer file sharing.
A separate storage network for e.g. iSCSI assumes that all clients and the TN server share that network, so no asymmetric routing occurs. That of course is perfectly reasonable. Same for e.g. NFS for VMware.
But placing mangement in a separate network does not work unless the management station is in that same network. Just like with the storage examples.
And yes, with Proxmox (or ESXi) the host usually does not have IP addresses in those bridge/vSwitch networks used for VMs or containers. And you can do the same with TN.
Only services running on the host all share a single stack. Which never happens with Proxmox because Proxmox does not offer file sharing.
#26
25.7, 25.10 Series / Re: NDP proxy in an HA setup?
Last post by Monviech (Cedrik) - Today at 09:21:17 AM@Patrick
If you feel like testing something, I added a simple depend on carp hook to the plugin. If you build/patch the plugin with it, it will make sure there is only one running instance on the current master. It only triggers on CARP transitions, there is no guard against starting the service manually on the backup (just fyi to keep in mind). The ndp-proxy-go binary doesn't need any changes, it's the current one from the opnsense repo.
- You must use "Proxy router advertisements", and do not use any RA daemons running on the OPNsense itself. As stated in above posts thats currently not possible due to missing features
- You must use "Install host routes"
- Best would be to also use "Neighbor cache file" so in case of CARP flapping there is less downtime
-> Some downtime during transitions is always expected. The upstream (ISP) router must learn the new MAC address after a failover. I don't know how long that takes, but I assume less than a minute (most NDP states have a 60s lifetime). But IPv6 failover (when its truly end to end, no fake identity with NAT or virtual addresses) is never really interruption free.
I feel like essentially this is all it should take to HA enable the plugin, yet I would really like some feedback before implementing this "for real". Thank you if you take a look at it :)
https://github.com/Monviech/plugins/tree/ndp-proxy-carp
If you feel like testing something, I added a simple depend on carp hook to the plugin. If you build/patch the plugin with it, it will make sure there is only one running instance on the current master. It only triggers on CARP transitions, there is no guard against starting the service manually on the backup (just fyi to keep in mind). The ndp-proxy-go binary doesn't need any changes, it's the current one from the opnsense repo.
- You must use "Proxy router advertisements", and do not use any RA daemons running on the OPNsense itself. As stated in above posts thats currently not possible due to missing features
- You must use "Install host routes"
- Best would be to also use "Neighbor cache file" so in case of CARP flapping there is less downtime
-> Some downtime during transitions is always expected. The upstream (ISP) router must learn the new MAC address after a failover. I don't know how long that takes, but I assume less than a minute (most NDP states have a 60s lifetime). But IPv6 failover (when its truly end to end, no fake identity with NAT or virtual addresses) is never really interruption free.
I feel like essentially this is all it should take to HA enable the plugin, yet I would really like some feedback before implementing this "for real". Thank you if you take a look at it :)
https://github.com/Monviech/plugins/tree/ndp-proxy-carp
#27
General Discussion / Re: My pf ruleset causing clie...
Last post by OPNenthu - Today at 08:01:01 AMIt helps me to write this out and make sure I got the full picture-
I'm not seeing the issue in Proxmox NOT because it is designed differently than TrueNAS. It's because there is no non-default return path for management traffic. Management requests always go to the configured interface with the default IP and gateway and reply from the same, because I don't have any interface with IPs on direct connected networks.
The VM/container bridge, even though it's on a separate interface, cannot respond anyway as it's unconfigured. Because it's VLAN-aware, VMs/LXCs that are tagged on the bridge are isolated to the respective networks.
Similarly, TrueNAS VMs/LXCs can go on a bridge with VLANs as long as the bridge, its VLAN parents, and the parent IF are all unconfigured. It might need to be separate bridges in TN, I think, because there is no concept of a VLAN-aware bridge but I'm not certain. (The Aquantia NIC falls down in a layered scenario in my limited testing so far; seems like immature firmware/drivers from other reports).
---
Up to this point things make sense.
Where I'm getting tripped up still is that TrueNAS gives options for binding the UI and the services separately, and there are videos showing that TrueNAS can have different networks for iSCSI (such as for a SAN for Windows hypervisors) and for shares for office clients, for example.
I can imagine that they have a NIC on each network and bind the respective service to an IP on it, so in that case the service is directly connected on the respective subnet. There should be no routing for Hypervisor<->iSCSI or for client<->SMB.
Where does the management interface go? Is it available to all and locked down only with strong authentication?
Is the purpose of allowing the UI to be bound on a specific IP just so that people can't find it by typing in https://truenas.local?
---
I found one such thread on the TN forum that was funny. After you explained the limitation, the guy was upset and came up with an elaborate scheme involving intermediate switches and routing / firewall tricks to get his isolated management. He never updated to say if he had success, lol.
I'm not seeing the issue in Proxmox NOT because it is designed differently than TrueNAS. It's because there is no non-default return path for management traffic. Management requests always go to the configured interface with the default IP and gateway and reply from the same, because I don't have any interface with IPs on direct connected networks.
The VM/container bridge, even though it's on a separate interface, cannot respond anyway as it's unconfigured. Because it's VLAN-aware, VMs/LXCs that are tagged on the bridge are isolated to the respective networks.
Similarly, TrueNAS VMs/LXCs can go on a bridge with VLANs as long as the bridge, its VLAN parents, and the parent IF are all unconfigured. It might need to be separate bridges in TN, I think, because there is no concept of a VLAN-aware bridge but I'm not certain. (The Aquantia NIC falls down in a layered scenario in my limited testing so far; seems like immature firmware/drivers from other reports).
---
Up to this point things make sense.
Where I'm getting tripped up still is that TrueNAS gives options for binding the UI and the services separately, and there are videos showing that TrueNAS can have different networks for iSCSI (such as for a SAN for Windows hypervisors) and for shares for office clients, for example.
I can imagine that they have a NIC on each network and bind the respective service to an IP on it, so in that case the service is directly connected on the respective subnet. There should be no routing for Hypervisor<->iSCSI or for client<->SMB.
Where does the management interface go? Is it available to all and locked down only with strong authentication?
Is the purpose of allowing the UI to be bound on a specific IP just so that people can't find it by typing in https://truenas.local?
---
I found one such thread on the TN forum that was funny. After you explained the limitation, the guy was upset and came up with an elaborate scheme involving intermediate switches and routing / firewall tricks to get his isolated management. He never updated to say if he had success, lol.
#28
Hardware and Performance / Re: Dec740 connected to a USW-...
Last post by patient0 - Today at 07:23:41 AMQuote from: DEC740airp414user on December 27, 2025, 10:34:59 PMany device going over the wireguard tunnel can't access the router gui.What firewall rules have you created on the Wireguard interface?
#29
25.7, 25.10 Series / Re: DNS requests originating f...
Last post by patient0 - Today at 07:21:22 AMQuote from: wewyweww on Today at 06:53:00 AMI do not use the firewall for DNS or DHCP. However, when I do a DNS query from a client on the LAN, the originating IP address of the DNS request is the WAN IP on the WAN interface.If we are talking IPv4 then all traffic is NAT-ed to the WAN IP, including DNS queries.
#30
25.7, 25.10 Series / DNS requests originating from ...
Last post by wewyweww - Today at 06:53:00 AMHello all,
I've hit a wall trying to understand what is going on.
I do not use the firewall for DNS or DHCP. However, when I do a DNS query from a client on the LAN, the originating IP address of the DNS request is the WAN IP on the WAN interface.
I have a rule on the LAN interface that should be blocking these DNS queries, but I do not see the LAN source address at all and is not being blocked.
Thanks folks!
I've hit a wall trying to understand what is going on.
I do not use the firewall for DNS or DHCP. However, when I do a DNS query from a client on the LAN, the originating IP address of the DNS request is the WAN IP on the WAN interface.
I have a rule on the LAN interface that should be blocking these DNS queries, but I do not see the LAN source address at all and is not being blocked.
Thanks folks!
