"Recent posts
#81
German - Deutsch / OPNsense und Hyper-V
Last post by Andi_s75 - December 28, 2025, 11:36:48 AMHallo zusammen,
mein Name ist Andreas, ich bin 50 Jahre alt und seit rund 20 Jahren in der IT tätig. Aktuell erweitere ich meine Netzwerk‑ und Firewallkenntnisse – bisher haben mir in meiner Laufbahn solide Grundkenntnisse in diesem Bereich ausgereicht. Meine Netzwerkkenntnisse würde ich derzeit bei etwa 30 % einordnen.
Derzeit baue ich eine kleine Testumgebung auf, bestehend aus einem Hyper‑V‑Server (Windows Server 2025), einem Zyxel‑Switch GS1950‑8 sowie einer FritzBox 7490.
Aktuelle Konfiguration:
HYper-V Server mit 2 physikalische Nics.
OPNSense als VM - 2 Virtuelle Switche WAN/LAN
Nic 1 WAN DHCP Adresse 192.168.x.x von Fritzbox
Nic 2 LAN statische IP 172.16.1.254 OPNsense
VLANS
10 - MGMT - 172.16.10.254
20 - Server - 172.16.20.254
30 - Client - 172.16.30.254
40 - Drucker - 172.16.40.254
50 - WiFi - 172.16.50.254
Alles nach bestem Wissen konfiguriert. Als Einstiegshilfe dienten YouTube Videos. :-D
Ich benötige kurz Unterstützung bei der Konfiguration Verbindung Hyper-V LAN Schnittstelle und Switch best practise. Leider habe ich eine Fehler und ich vermute das liegt am Uplink zum Switch. Oder meine Testumgebung ist Schrott.
Besten Dank euch
Andreas
mein Name ist Andreas, ich bin 50 Jahre alt und seit rund 20 Jahren in der IT tätig. Aktuell erweitere ich meine Netzwerk‑ und Firewallkenntnisse – bisher haben mir in meiner Laufbahn solide Grundkenntnisse in diesem Bereich ausgereicht. Meine Netzwerkkenntnisse würde ich derzeit bei etwa 30 % einordnen.
Derzeit baue ich eine kleine Testumgebung auf, bestehend aus einem Hyper‑V‑Server (Windows Server 2025), einem Zyxel‑Switch GS1950‑8 sowie einer FritzBox 7490.
Aktuelle Konfiguration:
HYper-V Server mit 2 physikalische Nics.
OPNSense als VM - 2 Virtuelle Switche WAN/LAN
Nic 1 WAN DHCP Adresse 192.168.x.x von Fritzbox
Nic 2 LAN statische IP 172.16.1.254 OPNsense
VLANS
10 - MGMT - 172.16.10.254
20 - Server - 172.16.20.254
30 - Client - 172.16.30.254
40 - Drucker - 172.16.40.254
50 - WiFi - 172.16.50.254
Alles nach bestem Wissen konfiguriert. Als Einstiegshilfe dienten YouTube Videos. :-D
Ich benötige kurz Unterstützung bei der Konfiguration Verbindung Hyper-V LAN Schnittstelle und Switch best practise. Leider habe ich eine Fehler und ich vermute das liegt am Uplink zum Switch. Oder meine Testumgebung ist Schrott.
Besten Dank euch
Andreas
#82
25.1, 25.4 Series / Re: captive portal idletimeout...
Last post by Toon - December 28, 2025, 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!
#83
General Discussion / Re: My pf ruleset causing clie...
Last post by OPNenthu - December 28, 2025, 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.
#84
Hardware and Performance / Re: Dec740 connected to a USW-...
Last post by patient0 - December 28, 2025, 11:16:58 AMQuote from: DEC740airp414user on December 28, 2025, 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
#85
Hardware and Performance / Re: Dec740 connected to a USW-...
Last post by DEC740airp414user - December 28, 2025, 10:46:28 AMQuote from: patient0 on December 28, 2025, 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?
#86
General Discussion / Re: My pf ruleset causing clie...
Last post by Patrick M. Hausen - December 28, 2025, 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.
#87
25.7, 25.10 Series / Re: NDP proxy in an HA setup?
Last post by Monviech (Cedrik) - December 28, 2025, 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, it needs to be added later since rc.d script must be changed).
- 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
EDIT:
Tested the failover from the perspective of a client. Master was shut down.
IPv6 converged naturally between 10-20 seconds.
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, it needs to be added later since rc.d script must be changed).
- 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
EDIT:
Tested the failover from the perspective of a client. Master was shut down.
IPv6 converged naturally between 10-20 seconds.
Code Select
~ % ping6 ipv6.google.com
PING6(56=40+8+8 bytes) 2003:a:XXXX:XXXX:308f:4dc8:f9d9:d0e7 --> 2a00:1450:4016:801::200e
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=1 hlim=117 time=11.981 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=2 hlim=117 time=11.574 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=3 hlim=117 time=11.594 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=4 hlim=117 time=11.641 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=5 hlim=117 time=12.349 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=6 hlim=117 time=11.837 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=7 hlim=117 time=11.777 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=8 hlim=117 time=11.781 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=9 hlim=117 time=11.808 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=10 hlim=117 time=11.765 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=11 hlim=117 time=11.780 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=12 hlim=117 time=11.560 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=13 hlim=117 time=11.695 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=14 hlim=117 time=12.090 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=29 hlim=117 time=11.853 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=30 hlim=117 time=11.841 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=31 hlim=117 time=11.710 ms
16 bytes from 2a00:1450:4016:801::200e, icmp_seq=32 hlim=117 time=11.377 ms #88
General Discussion / Re: My pf ruleset causing clie...
Last post by OPNenthu - December 28, 2025, 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.
#89
Hardware and Performance / Re: Dec740 connected to a USW-...
Last post by patient0 - December 28, 2025, 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?
#90
25.7, 25.10 Series / Re: DNS requests originating f...
Last post by patient0 - December 28, 2025, 07:21:22 AMQuote from: wewyweww on December 28, 2025, 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.
