"Recent posts
#1
General Discussion / Re: weird issues with network
Last post by meyergru - Today at 12:24:45 AMFrom your description, the main obstacle is the complexity of your setup and the lack of a controlled baseline for troubleshooting. You describe several different symptoms without having established where each failure occurs. Systematic fault isolation comes before BSD-specific expertise.
A crucial distinction here is between configuration and runtime state. An unchanged configuration does not imply unchanged behaviour. DNS answers, DHCP leases, ARP caches and firewall connection states change during normal operation. Security products can update signatures, reputation data and blocklists automatically. The same configured policy can therefore produce different results as its inputs and state change. Looking for manual configuration changes will not explain those differences, and the absence of configuration-change logs is entirely unsurprising.
You have also combined several access-control mechanisms whose interactions need to be understood. Some combinations have documented restrictions: Zenarmor and Suricata in IPS mode, when using netmap, require separate interfaces because they cannot both own the same netmap interface. That is one concrete example of why individually useful security products cannot simply be combined without checking interoperability.
Running the Proxmox firewall alongside the OPNsense firewall introduces another independent filtering layer. Traffic dropped before reaching the VM cannot appear in the guest firewall's logs. Each layer needs to be investigated at the point where it acts.
Wireless networking - being unreliable at best - adds further variables. Access points may perform ARP broadcast-to-unicast conversion or multicast-to-unicast conversion, introducing additional processing and learned state. These features can require disabling for particular applications; TP-Link's own Omada guidance for Sonos is an example. A connected Wi-Fi client therefore does not establish that every relevant type of traffic is being delivered correctly.
These examples illustrate the diagnostic problem; they do not establish suspected causes of your particular failures.
The important point is that these variables create combinations. The diagnostic search space grows multiplicatively as configuration choices, runtime states and interactions are combined. Understanding each component individually is insufficient if you cannot also account for their combined behaviour. Thus, you need a minimal, known-working baseline, one reproducible symptom at a time, and tests that locate where communication breaks down. Reinstalling everything and restoring the same configuration also restores any configuration problems it contains, so Proxmox does not help you there, either.
Realistically, you are unlikely to find volunteers willing to reconstruct and untangle this entire environment free of charge. A forum can help with specific, sufficiently isolated problems. You need to do the groundwork yourself: reduce the complexity of your setup and present one clearly isolated, reproducible failure at a time.
A crucial distinction here is between configuration and runtime state. An unchanged configuration does not imply unchanged behaviour. DNS answers, DHCP leases, ARP caches and firewall connection states change during normal operation. Security products can update signatures, reputation data and blocklists automatically. The same configured policy can therefore produce different results as its inputs and state change. Looking for manual configuration changes will not explain those differences, and the absence of configuration-change logs is entirely unsurprising.
You have also combined several access-control mechanisms whose interactions need to be understood. Some combinations have documented restrictions: Zenarmor and Suricata in IPS mode, when using netmap, require separate interfaces because they cannot both own the same netmap interface. That is one concrete example of why individually useful security products cannot simply be combined without checking interoperability.
Running the Proxmox firewall alongside the OPNsense firewall introduces another independent filtering layer. Traffic dropped before reaching the VM cannot appear in the guest firewall's logs. Each layer needs to be investigated at the point where it acts.
Wireless networking - being unreliable at best - adds further variables. Access points may perform ARP broadcast-to-unicast conversion or multicast-to-unicast conversion, introducing additional processing and learned state. These features can require disabling for particular applications; TP-Link's own Omada guidance for Sonos is an example. A connected Wi-Fi client therefore does not establish that every relevant type of traffic is being delivered correctly.
These examples illustrate the diagnostic problem; they do not establish suspected causes of your particular failures.
The important point is that these variables create combinations. The diagnostic search space grows multiplicatively as configuration choices, runtime states and interactions are combined. Understanding each component individually is insufficient if you cannot also account for their combined behaviour. Thus, you need a minimal, known-working baseline, one reproducible symptom at a time, and tests that locate where communication breaks down. Reinstalling everything and restoring the same configuration also restores any configuration problems it contains, so Proxmox does not help you there, either.
Realistically, you are unlikely to find volunteers willing to reconstruct and untangle this entire environment free of charge. A forum can help with specific, sufficiently isolated problems. You need to do the groundwork yourself: reduce the complexity of your setup and present one clearly isolated, reproducible failure at a time.
#2
26.7 Series / Re: [SOLVED] Quectel EC25‑E / ...
Last post by (MARLOO) - October 24, 2026, 11:07:01 PMI'm leaning towards the Huawei B535-232 LTE Cat 7, mainly for the price. For less money, I don't think I'd find anything comparable with external SMA connectors, Gigabit Ethernet, and good backup-WAN suitability.
For more control I'd consider an industrial router like the Teltonika RUT950 100+ euros (but less powerfull) or the TELTONIKA RUTX11 which is 400+ euros.
Also I'm unsure about LTE band support and whether it's carrier-locked. The Huawei may offer fewer option controls, but I know it works reliably with my band provider.
Once everything is working behind OPNsense, I may open a new post with my WAN failover configuration
For more control I'd consider an industrial router like the Teltonika RUT950 100+ euros (but less powerfull) or the TELTONIKA RUTX11 which is 400+ euros.
Also I'm unsure about LTE band support and whether it's carrier-locked. The Huawei may offer fewer option controls, but I know it works reliably with my band provider.
Once everything is working behind OPNsense, I may open a new post with my WAN failover configuration
#3
26.7 Series / Re: [SOLVED] Quectel EC25‑E / ...
Last post by nero355 - October 24, 2026, 10:27:21 PMQuote from: (MARLOO) on October 24, 2026, 08:08:43 PMDo you have any experience with either of them, or would you recommend a different external LTE router for this use case?Actually I am looking forward to your own experience with either one of those (...or perhaps a totally different 3th/4th model that you might discover...) in case I ever need one in the future ;)
#4
26.1, 26,4 Series / update and change to OpenVPN
Last post by Diggy - October 24, 2026, 10:18:07 PMI just updated from 26.1.11_6 to 26.1.11_10. I noticed in the release notes that OpenVPN configuration has made some change to the user/group settings. I have not yet configured OpenVPN but plan to soon. Do I have to do something special for that user/group change to be applied when I do configure it? What does that change affect?
#5
Tutorials and FAQs / Re: Cannot install fish shell ...
Last post by cookiemonster - October 24, 2026, 08:49:18 PMthere isn't a proper way.
You have a repository: opnsense repo. This one has all the appliance needs to do what is expected to do by the project.
Then you can add another package by using another repo. By doing that however, you are very likely to have update/upgrade problems in the future. For this reason it is not a proper nor recommended way.
It is still doable but then you walk into the likely problem mentioned above.
There will be suggestions of course like temporarily enabling a repo, transfering the package, etc. and that's fine but maybe you can consider using one of the included shells? Using your preferred shell from your ssh connection?
You have a repository: opnsense repo. This one has all the appliance needs to do what is expected to do by the project.
Then you can add another package by using another repo. By doing that however, you are very likely to have update/upgrade problems in the future. For this reason it is not a proper nor recommended way.
It is still doable but then you walk into the likely problem mentioned above.
There will be suggestions of course like temporarily enabling a repo, transfering the package, etc. and that's fine but maybe you can consider using one of the included shells? Using your preferred shell from your ssh connection?
#6
General Discussion / Re: Networking Question - Isol...
Last post by talespin - October 24, 2026, 08:20:11 PMHi Everyone,
Posting update.
I was able to accomplish what I wanted and this is how I did it.
I am using nic xxv-710 on my server(using single port and SR-IOV). Created multiple virtual functions and assigned them to VM's. While creating VM's I was able to provide vlan tag to each VM and also configured VLAN's under OPNSense(running on a tiny pc). Then created firewall rules on these VLAN's. All working good.
Thank you
Posting update.
I was able to accomplish what I wanted and this is how I did it.
I am using nic xxv-710 on my server(using single port and SR-IOV). Created multiple virtual functions and assigned them to VM's. While creating VM's I was able to provide vlan tag to each VM and also configured VLAN's under OPNSense(running on a tiny pc). Then created firewall rules on these VLAN's. All working good.
Thank you
#7
26.7 Series / Re: [SOLVED] Quectel EC25‑E / ...
Last post by (MARLOO) - October 24, 2026, 08:08:43 PMQuote from: nero355 on October 24, 2026, 07:16:32 PMI am curious : Which one did you buy exactly ?
I am currently evaluating either a Huawei B535-232 (LTE Cat 7) or a ZTE MF296R (LTE Cat 6). Do you have any experience with either of them, or would you recommend a different external LTE router for this use case? Ideally I am looking for something reliable, 300Mbps with an Ethernet port for OPNsense, external SMA antenna connectors MIMO and good LTE performance as a backup WAN
#8
German - Deutsch / Re: Glasfaser ONT
Last post by k0ns0l3 - October 24, 2026, 07:34:50 PMDanke ;))
lg k0ns0l3
lg k0ns0l3
#9
Virtual private networks / Re: Need help with routing all...
Last post by BoNetTech - October 24, 2026, 07:34:25 PMHi,
I have not tested this exact setup with IVPN, so these are suggestions for what to check.
1) Find out whether the problem is DNS or routing. From a client on the VLAN, try to reach a public IP address directly, then try a name. If the IP works and the name does not, it is DNS only. If the IP does not work either, the routing or the outbound NAT is the problem.
2) Rule order on the VLAN. If your VLAN has a rule that sends everything through the VPN gateway, it may also send the traffic meant for the firewall itself, such as DNS to the VLAN address, into the tunnel. Put a pass rule above it, without a gateway, that allows the VLAN to reach the firewall address on the DNS port. Then use the tunnel DNS address only for the traffic that really has to go through the VPN.
3) The tunnel DNS address. 172.16.0.1 is inside the tunnel, so it is only reachable if the traffic is routed through the VPN gateway. Check that your peer allows all addresses, and that the gateway for the WireGuard interface is up in System, Gateways.
4) The endpoint name. The firewall resolves the endpoint hostname with its own DNS settings, not through the VLAN. If it fails there, check the DNS servers in System, Settings, General. Using the IP address as the endpoint also works, with the drawback that you have to update it if the provider changes it.
5) To see what really happens, run a packet capture on the WireGuard interface while a client tries to resolve a name. If you see the queries leave and no answers come back, the problem is on the tunnel side; if you see nothing, the traffic is not reaching the tunnel.
Which one is it in your case, the IP test or the name test?
Sergio
I have not tested this exact setup with IVPN, so these are suggestions for what to check.
1) Find out whether the problem is DNS or routing. From a client on the VLAN, try to reach a public IP address directly, then try a name. If the IP works and the name does not, it is DNS only. If the IP does not work either, the routing or the outbound NAT is the problem.
2) Rule order on the VLAN. If your VLAN has a rule that sends everything through the VPN gateway, it may also send the traffic meant for the firewall itself, such as DNS to the VLAN address, into the tunnel. Put a pass rule above it, without a gateway, that allows the VLAN to reach the firewall address on the DNS port. Then use the tunnel DNS address only for the traffic that really has to go through the VPN.
3) The tunnel DNS address. 172.16.0.1 is inside the tunnel, so it is only reachable if the traffic is routed through the VPN gateway. Check that your peer allows all addresses, and that the gateway for the WireGuard interface is up in System, Gateways.
4) The endpoint name. The firewall resolves the endpoint hostname with its own DNS settings, not through the VLAN. If it fails there, check the DNS servers in System, Settings, General. Using the IP address as the endpoint also works, with the drawback that you have to update it if the provider changes it.
5) To see what really happens, run a packet capture on the WireGuard interface while a client tries to resolve a name. If you see the queries leave and no answers come back, the problem is on the tunnel side; if you see nothing, the traffic is not reaching the tunnel.
Which one is it in your case, the IP test or the name test?
Sergio
#10
26.7 Series / Re: Wireguard vs. DNS resoluti...
Last post by oc - October 24, 2026, 07:31:55 PMQuote from: Bob.Dig on October 24, 2026, 10:41:51 AMI agree that it's a bit convoluted, but it does follow various segmentation/filtering best practices (from the logical standpoint). For instance, I can control what reaches the Flint, and what the Flint can reach (except what's flowing through the encrypted tunnels, but that's flowing through different VLANs through opnsensee, so it's contolled at that point). But by having the Flint2 (which is also enabled as a wireguard server) behind the opnsense, I have limited IPs/countries/blacklists that can/not reach it inbound, and that it can/not reach when reaching out. The result - very very clean logs on the Flint.Quote from: oc on October 24, 2026, 02:28:06 AMBut while it works it's a quite cool setupI don't think so.
Notwithstanding that, I'm always open to improve the model(s). What would you recommend/change?
Quote from: Bob.Dig on October 24, 2026, 10:41:51 AMNone the less, what happens if you don't monitor the gateway? There is often no point in monitoring it anyway.Unfortunately, that won't resolve the issue - I have tried that. Apparently, even with ongoing monitoring disabled, dpinger still looks at the health of the gateway at boot time. So the results have been mixed, whether ongoing monitoring is enabled or disabled. Sometimes some routes are active after a reboot, other times they are not (same routes). It's really quite random. But, as mentioned, I can live with that, as a compromise. But I'd like to get this fixed, as long as it doesn't imply any changes that are likely to be undone at the next (big) opnsense update.
Thanks, and have a good weekend,
OC
