Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - tigo003

#1
Since upgrading to 25.7.6, my wireguard connections seem to work fine for a while then, either

i) not pass any traffic yet appear connected with a handshake,

ii) wireguard status icon turning into a black question mark, and no traffic.

iii) Go down completely.

As I have a couple of WG connections in a Group gateway that has a final fallback to the WAN connection, the fallback to the WAN is messy. So, I ran a machine on a single WG connection by itself, and the same issue appears.

Release notes for 25.7.6 state the update introduced  wireguard: add debug option to instances. Nothing in particular stands out in the messaging. The dpinger on the other hand reports losses and gateway fallover works.

Then, there are times when the dpinger reports the connection is up, & WG status reports a handshake and some little traffic. But, when I try to do a traceroute, all the traffic stops at the gateway.

I've had to delete & recreate all WG connections at the service provider & on opnsense, and change the IP-address scheme. Then, they would work for 2 days and crash again.

My configuration and setup had been stable, without any changes for quite sometime, 6+ months....Any thoughts whether this could just be an opnsense bug? If so, how do we report it, and what diagnostic report, or testing do we submit.
#2
This is still an issue in OPNsense 25.7.6, as it has not been resolved.

An OpenVPN tunnel as a gateway set by itself in the rules, works fine. Place that OpenVPN gateway in a group, and it is automatically skipped.
#3
Alright will give it a go, and see how it fairs.
#4
Seeking some guidance from anyone that had ventured down this path.

I'm currently running ISC dhcp4, with static mappings for clients, some with different DNS servers and some with different gateways.

How did you go about sorting these out if you've migrated across to the KEA server instance?

Looking at the guidelines by OPNsense,"Configure kea dhcp 4 manually, requires supplying your own /usr/local/etc/kea/kea-dhcp4.conf file (advanced users only)".

It'll require,
Downloading the .conf file, - running a script to convert my isc dhcp4 mappings across to the same format, then, uploading the conf file, replacing the one on the server, and then starting up the service.

All future changes are to be done by doing manual console - terminal edits to the .conf file.

What did you do?

Thanks,
#5
The recent update that was rolled out a couple of days ago - solves the issue. All is working correctly now.
#6
Done - just sent the requested feedback.
Thank you,
#7
Just ran a health check audit, and similarly, had a similar error 2 in regards to sysctl.conf - size issue.

#8
I'm now getting the following error after the recent update of Zenarmor.

Zenarmor -    v.1.17.1
Zenarmor Application DB: 1.17.24042216

I haven't changed anything with my configuration - and Zenarmor is strictly configured for the LAN interfaces across different VLANs.

Is anyone facing a similar problem? 

"Possible deployment misconfiguration: devices with public IP addresses detected"  To correct this, please see the following document: https://www.zenarmor.com/docs/opnsense/installing/web-ui-initial-configuration#3-deployment-mode--interface-selection