Recent posts

#1

26.1, 26,4 Series / Re: WireGuard not starting cor...

Last post by franco - Today at 03:36:19 PM

All I can see from these reports is that DNS resolution isn't working when the tunnel is supposed to come up (if the message is actually the error to look into and not a cosmetic oddity as it could be restarted later anyway). A reboot is also the most likely point DNS resolution isn't up and running yet or is worst case routed through a tunnel that isn't up yet.


Cheers,
Franco

#2

General Discussion / Re: Device Monitor - a tool fo...

Last post by mooh - Today at 03:30:38 PM

I would like to see this software rolled into one plugin together with the device discovery service added to OPNsense recently. There's some overlap in functionality.

Then again, unless the information is accumulated over a multi-layer network, i.e. across routers, I could just as well query the network management software for it. I can see how filtering MACs into FW Aliases can be useful if one manages networks on the basis of MAC addresses, but I don't.

#3

26.1, 26,4 Series / Re: WireGuard not starting cor...

Last post by os914964619 - Today at 03:25:32 PM

I started seeing the same exact issue as you that started happening on all my routers. Some regression was introduced in the previous release (26.1.6) or the one before that (26.1.5). I don't know which one it was because 26.1.5 didn't require a reboot so that could have been the culprit but I don't know because I didn't reboot. I only had to reboot after applying 26.1.6, and it started happening on all my routers after that reboot.

https://forum.opnsense.org/index.php?topic=51578.msg

Other people have reported it as well:

https://forum.opnsense.org/index.php?topic=50748.msg
https://forum.opnsense.org/index.php?topic=32232.msg

And if you do a search, there's many, many, more older posts with the same problem.

I'm not sure what changed in the last month or two, but I have never changed my configuration or had this issue up until I applied two updates and then rebooted.

So the issue is either a regression in 26.1.5 or 26.1.6

#4

Zenarmor (Sensei) / Re: os-sunnywalley plugin inst...

Last post by sy - Today at 03:21:05 PM

Hi,

Can you check via telnet or similar tool that updates.zenarmor.net is reachable on TCP port 443?

#5

General Discussion / Re: Flashing OPNSense .img.bz2

Last post by drosophila - Today at 03:16:41 PM

From which mirror did you fetch that file? It's always possible that one may be borked for some reason. That's what the checksums are for. I usually get the file from one mirror and the checksums from another. Then the public key from a third and the signature from a fourth, or, if possible, from another source like the website or official blog. But for starters the checksum must match.
I just downloaded the file you probably got from the default mirror and checked:
SHA256 (OPNsense-26.1.2-dvd-amd64.iso.bz2) = 8b81427b049ca291bed982a85c6eb821e9887f70b79c1d8183c24721e037f938
This does match the checksum file from turkish mirror.

#6

26.1, 26,4 Series / Re: WireGuard not starting cor...

Last post by franco - Today at 02:57:29 PM

You can try the support offering we have which fits this problem scope. Assuming everyone suffers from a low quality integration/implementation isn't helpful. It's also not how this integration/implementation is going to improve without constructing the actual problem in a way it makes sense with the code at hand.


Cheers,
Franco

#7

26.1, 26,4 Series / Re: WireGuard not starting cor...

Last post by chemlud - Today at 02:50:37 PM

OK, x tunnels, all WG with DynDNS, of which x-1 come up normally after opnsense reboot, while 1 tunnel doesn't, restarting WG instance, dis-/enabling does nothing to bring the tunnel up, as does any operation you can imagine on the remote WG instance.

But obtaining a fresh WAN IP on opnsense brings up this tunnel.

All the tunnels up and running for 5+ years, problem started some weeks ago.

What to make out of this?

As written somewhere else: This very same tunnel went down at a random time of day recently, again only a fresh WAN IP could recover the tunnel. No other operation.

#8

General Discussion / Re: How do IPv6 Router Adverti...

Last post by mooh - Today at 02:44:35 PM

Based on what @mooh wrote the default for these devices is that they use link-local addresses, which limits their access to what the hub provides them from its own uplink to the IOT network.  That is easy enough to firewall because all you would have to do is block the hub and everything downstream of it is also walled off.
ey are not able to get beyond the IOT network, but your controllers on other VLANs can still get to them (if their rules permit).

Exactly. Don't worry about the thread devices. They only know the thread network and can't get out. Any traffic between the thread network and the rest of the world is via the border-router. The fact that the thread network uses link-local IPv6 addressing is entirely irrelevant for your LAN design.

Of course, these are just the basics. In real life, it can get more complex quickly:

• You'll probably want more than 1 border-router.
• Matter devices are also available as WiFi or Ethernet devices. They should be on the same L2 network as the border-routers, i.e. your IoT network.
• One of the recent revisions of Matter introduced a feature to allow Matter devices to communicate with the world. Although still only via border-routers - I think -, it breaks the notion of strict locality that is/was one of the highlights of Matter to me.

#9

26.1, 26,4 Series / Re: WireGuard not starting cor...

Last post by franco - Today at 02:35:27 PM

> Devs will say: Wrong config, will break some day.

No, but what we're saying is:

> "Name does not resolve: `xx.yyy.de:51820'

That's a DNS error. No dev can reasonable resolve xx.yyy.de for you.


Cheers,
Franco

#10

Hardware and Performance / Re: N150 Mini PC, RTL8153, AX8...

Last post by drosophila - Today at 02:33:06 PM

I only consider a NIC reliable when it
1) succeeds an iperf3 -P4 (P4 is important to stress SMP and get max throughput on slower CPUs) for at least 10 minutes, once as sender and receiver AND
2) succeeds in not locking up with an iperf3 -P4 --bidir (--bidir is the kill-switch for NICs/drivers). It may slow down on either direction, but it must not lock up or crash even once during the 10 minute test run.

This is for SOHO use. For serious business use anything less than sustained full speed in both directions with --bidir is not acceptable.