"Recent posts
#1
26.7, 26.10 Series / Re: ACME, sftp upload - New Cl...
Last post by keeka - Today at 11:01:07 AMCheck SSH manually from OPNsense to the respective hosts. Perhaps you're missing authorized hosts (opnsense) or public keys (ubuntu side). The keys and known_hosts used by acme automations are in /var/etc/acme-client/sftp-config/
#2
High availability / Re: Some direction for HA conf...
Last post by Lipaz - Today at 10:55:35 AMHello and thanks for the reply.
i have the ability to manage them on the IP that the interface holds and not the VRRP address.
so i am okay with the process
for your question, virtual switch
i have the ability to manage them on the IP that the interface holds and not the VRRP address.
so i am okay with the process
for your question, virtual switch
#3
26.7, 26.10 Series / Re: Wireguard packet loss
Last post by keeka - Today at 10:50:35 AMGood to hear you have it working. I plan on doing something similar in the near future. A lightweight VPS to 'proxy' services, including mail, on my home network.
#4
General Discussion / Re: Please Make a Donation to ...
Last post by passeri - Today at 10:26:53 AMYes, I have decided to make the switch next week after I return, planning to make some use of GeoIP features in rules.
#5
Virtual private networks / Re: OPNsense + AirVPN (WireGua...
Last post by BoNetTech - Today at 09:00:08 AMPort forwarding through a VPN on OPNsense usually fails in one of three places. Let's check them in order, so you can see where the packets stop:
1. Does the traffic arrive at all?
From a machine OUTSIDE your network (e.g. phone on mobile data, not the LAN – NAT reflection would confuse the test), try to reach the AirVPN IP on port 45678. At the same time open Firewall > Log Files > Live View and filter on destination port 45678.
– Nothing shows up: the problem is on the AirVPN side. Check in their client area that the port is TCP, assigned to your account, and forwarded to IPv4.
– It shows up as blocked: go to step 2.
– It shows up as passed: go to step 3.
2. Port forward and firewall rule (Firewall > NAT > Port Forward)
– Interface: the AirVPN WireGuard interface (the one the traffic arrives on, not the Plex VLAN).
– Protocol: TCP. Destination: the interface address of the AirVPN interface (or "any"). Destination port: 45678.
– Redirect target IP: 10.20.30.40, target port: 32400.
– Filter rule association: "Add associated filter rule" (or create the pass rule yourself on the AirVPN interface: TCP, destination 10.20.30.40, port 32400).
3. Replies must go back through the tunnel, not out the WAN
The Plex VLAN has a policy-routing rule with AirVPN_GW, which is good for outgoing traffic. For replies, check that the rule created in step 2 does not have "disable reply-to" set, and that the WireGuard interface has its gateway assigned (System > Gateways). Packet capture (Interfaces > Diagnostics > Packet Capture) on the WireGuard interface and on the Plex VLAN, port 45678 / 32400, shows whether the replies leave through the wrong interface.
Also: outbound NAT for the Plex VLAN through the AirVPN interface must be in place (Firewall > NAT > Outbound), otherwise the Plex server cannot reach the Internet through the tunnel.
If it still fails, please post: (a) a screenshot of your NAT port forward rule, (b) the Live View lines for port 45678, (c) the result of a packet capture on the WireGuard interface.
Sergio
1. Does the traffic arrive at all?
From a machine OUTSIDE your network (e.g. phone on mobile data, not the LAN – NAT reflection would confuse the test), try to reach the AirVPN IP on port 45678. At the same time open Firewall > Log Files > Live View and filter on destination port 45678.
– Nothing shows up: the problem is on the AirVPN side. Check in their client area that the port is TCP, assigned to your account, and forwarded to IPv4.
– It shows up as blocked: go to step 2.
– It shows up as passed: go to step 3.
2. Port forward and firewall rule (Firewall > NAT > Port Forward)
– Interface: the AirVPN WireGuard interface (the one the traffic arrives on, not the Plex VLAN).
– Protocol: TCP. Destination: the interface address of the AirVPN interface (or "any"). Destination port: 45678.
– Redirect target IP: 10.20.30.40, target port: 32400.
– Filter rule association: "Add associated filter rule" (or create the pass rule yourself on the AirVPN interface: TCP, destination 10.20.30.40, port 32400).
3. Replies must go back through the tunnel, not out the WAN
The Plex VLAN has a policy-routing rule with AirVPN_GW, which is good for outgoing traffic. For replies, check that the rule created in step 2 does not have "disable reply-to" set, and that the WireGuard interface has its gateway assigned (System > Gateways). Packet capture (Interfaces > Diagnostics > Packet Capture) on the WireGuard interface and on the Plex VLAN, port 45678 / 32400, shows whether the replies leave through the wrong interface.
Also: outbound NAT for the Plex VLAN through the AirVPN interface must be in place (Firewall > NAT > Outbound), otherwise the Plex server cannot reach the Internet through the tunnel.
If it still fails, please post: (a) a screenshot of your NAT port forward rule, (b) the Live View lines for port 45678, (c) the result of a packet capture on the WireGuard interface.
Sergio
#6
Virtual private networks / Re: Noob trying to get Wiregua...
Last post by BoNetTech - Today at 08:56:42 AMThanks, the screenshots help. A few observations, but let's do one thing at a time:
You're reaching the GUI on 192.168.99.1 (MGNT99), so you're not locked out anymore, correct? Please back up config.xml now (System > Configuration > Backups) before changing anything else.
Interfaces > Assignments shows no IPv4 on LAN. Is that intentional (LAN only as parent for the VLANs), or did you remove it?
I don't see a rule allowing DNS (TCP/UDP 53) from XBOXS10, PERSONAL20 and GUEST30 to "This Firewall". If your clients use the firewall as DNS server, that traffic is blocked. Which DNS server do those VLANs get from DHCP?
The rule "KSWITCHENGAGE" on WAN looks like an inbound block rule. That is not a kill switch (WAN already blocks inbound). We can do the kill switch last.
About 127.0.0.1: please check System > Settings > General (DNS servers) and Services > Unbound DNS > General > Network Interfaces (Localhost should be selected) and tell me what you see.
Which problem is the most urgent for you right now: no DNS on the VLANs, or no traffic through Proton?
Sergio
You're reaching the GUI on 192.168.99.1 (MGNT99), so you're not locked out anymore, correct? Please back up config.xml now (System > Configuration > Backups) before changing anything else.
Interfaces > Assignments shows no IPv4 on LAN. Is that intentional (LAN only as parent for the VLANs), or did you remove it?
I don't see a rule allowing DNS (TCP/UDP 53) from XBOXS10, PERSONAL20 and GUEST30 to "This Firewall". If your clients use the firewall as DNS server, that traffic is blocked. Which DNS server do those VLANs get from DHCP?
The rule "KSWITCHENGAGE" on WAN looks like an inbound block rule. That is not a kill switch (WAN already blocks inbound). We can do the kill switch last.
About 127.0.0.1: please check System > Settings > General (DNS servers) and Services > Unbound DNS > General > Network Interfaces (Localhost should be selected) and tell me what you see.
Which problem is the most urgent for you right now: no DNS on the VLANs, or no traffic through Proton?
Sergio
#7
General Discussion / Re: Please Make a Donation to ...
Last post by franco - Today at 08:31:29 AMThanks, make sure to try it indeed. It's easy to switch between versions until 27.1 is released which will lock you out of the business path until 27.4 is released as well.
Cheers,
Franco
Cheers,
Franco
#8
General Discussion / Re: How do I know if a non-off...
Last post by franco - Today at 08:29:26 AM> This is where I am 100% lost, if something is not an official plugin how do you know if it can be trusted?
I think this is the core problem: we cannot by default. That's why we started the community plugins so that we can have review, discussion and bugfix capabilities. But this was over a decade ago. Nowadays with AI assisted large blobs of code we can no longer screen submissions for official plugin inclusion. People just tend to publish it privately anyway because it beats going through a review process (it works, right?!). Whether that's with the source code open or not doesn't really matter; for one you can read the source code in the install archive and secondly there's still a lot of code to sift through which is just unlikely to be looked at by a human.
The other issue we see is that plugins were mainly meant to accommodate a (known) third party software for integration. Now the world is being reimplemented in Python scripts in a heartbeat so you don't even have that trust boundary anymore. Naturally, we don't really like to see these in the plugins because it puts the full maintenance load on the project once it has been accepted, which it can't be because it's not battle proven in the first place.
And, yes, it looks very pretty: code style, documentation, websites, communication. It is slowly becoming a red flag in this day and age.
FWIW, that's only my opinion. There's good things in this, but it still takes (human) effort to curate if this is something to be shared with the community. Otherwise everyone will just have to write their own plugins for themselves with the help of AI. This would be a bleak future. ;)
Cheers,
Franco
I think this is the core problem: we cannot by default. That's why we started the community plugins so that we can have review, discussion and bugfix capabilities. But this was over a decade ago. Nowadays with AI assisted large blobs of code we can no longer screen submissions for official plugin inclusion. People just tend to publish it privately anyway because it beats going through a review process (it works, right?!). Whether that's with the source code open or not doesn't really matter; for one you can read the source code in the install archive and secondly there's still a lot of code to sift through which is just unlikely to be looked at by a human.
The other issue we see is that plugins were mainly meant to accommodate a (known) third party software for integration. Now the world is being reimplemented in Python scripts in a heartbeat so you don't even have that trust boundary anymore. Naturally, we don't really like to see these in the plugins because it puts the full maintenance load on the project once it has been accepted, which it can't be because it's not battle proven in the first place.
And, yes, it looks very pretty: code style, documentation, websites, communication. It is slowly becoming a red flag in this day and age.
FWIW, that's only my opinion. There's good things in this, but it still takes (human) effort to curate if this is something to be shared with the community. Otherwise everyone will just have to write their own plugins for themselves with the help of AI. This would be a bleak future. ;)
Cheers,
Franco
#9
Zenarmor (Sensei) / Re: Newest version zenarmor ca...
Last post by RutgerDiehard - Today at 08:10:52 AMFixed here.
#10
Zenarmor (Sensei) / Zenarmor 2.7.1 → 2.7.2 upgrade...
Last post by RutgerDiehard - Today at 08:08:59 AMSetup: OPNsense [version], Zenarmor 2.7.2, local Elasticsearch reporting database.
What happened:
After upgrading Zenarmor from 2.7.1 to 2.7.2, restarting the packet engine caused OPNsense to kernel panic and reboot. After the reboot, every Zenarmor page in the OPNsense GUI showed only a grey page with a loading spinner.
What was fine:
pkg info showed os-sensei 2.7.2 installed, and pkg check -s os-sensei passed.
The eastpect engine and Elasticsearch were both running, and the cluster health was green.
The configd Zenarmor jobs were all returning OK.
Actual cause:
The browser console showed the Zenarmor entry JS and CSS files being blocked with a MIME type mismatch (text/html). The page was requesting index-CLn7932s.js and index-QZ9Oy0WF.css, but those files no longer exist. The 2.7.2 assets on disk are index-C_wF72l1.js and index-BdAypUN-.css, so the server was returning HTML instead.
The loader reads the entry filenames from two small pointer files:
/usr/local/opnsense/www/zenarmor/assets/js-file
/usr/local/opnsense/www/zenarmor/assets/css-file
Both still had their 2.7.1 dates and contents. They aren't owned by the package (pkg which returns "not found in the database"), which is why pkg check didn't catch them. It looks like the post-install step that rewrites them didn't complete, probably because the panic interrupted it.
Fix:
pkg install -f os-sensei
This regenerated both pointer files with the correct names, and the UI loaded normally afterwards.
Notes for anyone else:
If you see the spinner, open the browser devtools (F12) and check the Console for blocked index-*.js/.css files. Then compare the contents of js-file and css-file with the actual index-* files in that assets directory.
The panic on engine restart looks similar to the netmap generic adapter teardown race reported with earlier Zenarmor versions on 26.7. I'd avoid "Restart packet engine" until that's confirmed fixed.
Zenarmor's automatic bug report failed with a 500 from their server, so I've raised it separately.
What happened:
After upgrading Zenarmor from 2.7.1 to 2.7.2, restarting the packet engine caused OPNsense to kernel panic and reboot. After the reboot, every Zenarmor page in the OPNsense GUI showed only a grey page with a loading spinner.
What was fine:
pkg info showed os-sensei 2.7.2 installed, and pkg check -s os-sensei passed.
The eastpect engine and Elasticsearch were both running, and the cluster health was green.
The configd Zenarmor jobs were all returning OK.
Actual cause:
The browser console showed the Zenarmor entry JS and CSS files being blocked with a MIME type mismatch (text/html). The page was requesting index-CLn7932s.js and index-QZ9Oy0WF.css, but those files no longer exist. The 2.7.2 assets on disk are index-C_wF72l1.js and index-BdAypUN-.css, so the server was returning HTML instead.
The loader reads the entry filenames from two small pointer files:
/usr/local/opnsense/www/zenarmor/assets/js-file
/usr/local/opnsense/www/zenarmor/assets/css-file
Both still had their 2.7.1 dates and contents. They aren't owned by the package (pkg which returns "not found in the database"), which is why pkg check didn't catch them. It looks like the post-install step that rewrites them didn't complete, probably because the panic interrupted it.
Fix:
pkg install -f os-sensei
This regenerated both pointer files with the correct names, and the UI loaded normally afterwards.
Notes for anyone else:
If you see the spinner, open the browser devtools (F12) and check the Console for blocked index-*.js/.css files. Then compare the contents of js-file and css-file with the actual index-* files in that assets directory.
The panic on engine restart looks similar to the netmap generic adapter teardown race reported with earlier Zenarmor versions on 26.7. I'd avoid "Restart packet engine" until that's confirmed fixed.
Zenarmor's automatic bug report failed with a 500 from their server, so I've raised it separately.
