Messages

[don't]

Dear Yszty,

I think this is not the same problem because I don't have a mirror configuration - I have a single OpnSense on every site.

But unfortunatelly I can report, that the problem still exists in 24.7.2-amd64

I think a restart of service "Gateway Monitor"  can solve the problem after restart of OPNSense - but therefore I always have to be on the site and can't do anything from remote because in 90% OPNSense isn't reachable from outside after restart/update.

Please help.

Dear all,

I just updated to OPNsense 24.1.9_4-amd64 and after a reboot - problem is still present and not solved.

I didn't opened a ticket because have very little time (at the moment health-related and lot's of visits for myself at hospitals). I hope it will be solved.

The problem is a bit of critical because it can only easily be solved when I'm on the site where opnsense is installed (I can't solve it remotely because all outside WAN ports (NAT as well as OpenVPN) are unreachable).

... still present on 24.1.8

Dear All,

Problem is still present but not after every reboot. Since my last post, today it happened again and I do a reboot every Saturday.

I have a Multi-WAN Setup (but mostly one WAN interface is down because it is for test-reasons and blackout for primary WAN interface)

Perhaps these hints give you a possibility to check, where the problem could be. As I already wrote - this configuration worked for years with prior versions of OPNSense.

Restarting "Routing" Service seems to be enough - but only works when I'm local on site because all connections from WAN (including VPN) doesn't work.

OPNsense 24.1.6-amd64  --> still the same problem.

And yes - restart routing seems to work, just checked...

Why nobody (especially from OPNSense) tries to help???

... thanks for that info - I just updated to 24.1.6 and will report what's going on.

It will need some time because I only restart on weekend until this failure is solved.

BTW - I didn't read anything in changelog which could fix this behavior or do I overlook something?

It's still present in OPNsense 24.1.5_3-amd64

It seems that it's enough to manually restart service "routing".

I don't know, why I have such big problems after upgrade (and also some other people) and I don't know why nobody tries to solve this problem. It started after release of version 24 - before I used OPNSense for years without this problem. Installation was an upgrade from GUI.

I don't think that it is an unbound problem because I also can't reach IP-addresses (also internal when routed via OPNSense) and I also can't reach my NATted devices behind OPNSense from outside.

The problem is still persistend (but sporadically, I think every 2-5 restarts the problem occurs).

First what is eye-catching - on dashboard I can see, that crowdsec service isn't started.

This has nothing to do with the error, it seems that OPNSense has problems with starting all services correctly.

When I restart crowdsec it runs suddenly but problem is still present. After restarting service pf and routing it seems to work.

I hope somebody can solve this problem because so OPNSense is unstable at my side!!!

Dear all,

I don't know if this is a stable solution (fresh install and import of config) because it needs time to see if it worked or not.

My OPNSense has a restart-job every 1,4,7 day of the week. So I can say not every restart triggers the problem.

But today I have the same problems like stated above (nothing changed - only reboot in the night).

And now my new observation from today:

I didn't do changes in opnsense - it just rebooted by a cron job. After that, I can report the following behavior (which is very strange):

Just a small notice on my configuration:

2 WAN interfaces and 2 gateways -> OPNSense -> multiple internal VLAN Interfaces

--> gateway two is switched off and marked as down, so it is configured but not present.

Now the strange behavior (it's a little bit like reported above):

- normal internet usage (using browser) works without problems, therefor I didn't realize today in the morning that there is a problem
- routing between internal vlans works without problems
- one device in my technic-vlan can't connect to its cloud servers
- ping to different targets in the internet results in timeouts
- traceroute to same targets stops at OPNSense
- all connections from WAN-side stops working (no services were reachable - neither HAProxy on the OPNSense itself nor other NATed services behind OPNSense)
- no OPNSense update possible (can't reach servers)
- unbound worked as expected (I pinged a target which I never connected before so it couldn't be in the cache (I did a random google search and used the first hit to connect to, it was a local flower shop in a foreign country))
- all services were started (green arrows) except crowdsec-plugin
- starting crowdsec-plugin manually (after that also green arrow) doesn't change the behavior
- no errors in logfiles as I can see

--> rebooting OPNSense without any other interaction -> everything works fine direct after reboot

I don't know what could cause this strange behavior but I can imagine that this behavior causes a wide variety of error patterns for other users.

Dear all,

like I already wrote in my small post regarding wireguard problems - I just want to open a new topic to don't hijack the old one.

I'm very unsure whether there is a general problem which causes different symptoms (therefor I wrote my observations in the other topic).

Here a copy of my old post:

Hello,
I also have some strange problems after the update. I don't want to hijack this thread, but I think it might be the same origin that manifests differently for everyone.

OPNSense A:
Update and direct reboot
Everything seemed to work fine, but later today (day after update) I received error messages that some servers were not reachable - cause a DNS problem. According to the GUI, Unbound was not running - BUT the Internet via browser on the clients was working, so part of the DNS server must have been running. A reboot of OPNSense seemed to have fixed the problem - but I'll have to wait and see tomorrow.

OPNSense B:
Update and direct reboot
- A device can no longer connect to its cloud server.
I can address the device within my internal network (several VLANs routed via OPNSense), so the routing must basically work
- Internet access on my test client worked, websites could be loaded
- a "ping google.de" on the same test client shows no connection
- a "tracert google.de" stops at the OPNSense
- DNS worked, as both of the above commands were able to resolve an IP. I tried it with 3 different hosts, always the same behavior
- a restart of Unbound brought no change
- I checked to see if there was another update available on the OPNSense - the update routine could not connect to the update server either
After rebooting the OPNSense, everything seemed to work again (device had cloud connection, ping worked again, tracert worked again) - I did no other changes!

P.S. My Wireguard worked at least after the second reboot, before that I don't know.

Both OPNSense machines have been running for several years, nothing was changed in the configurations before the update. So it seems that something is sporadically unstable.

Hello,
I also have some strange problems after the update. I don't want to hijack this thread, but I think it might be the same origin that manifests differently for everyone.

OPNSense A:
Update and direct reboot
Everything seemed to work fine, but later today (day after update) I received error messages that some servers were not reachable - cause a DNS problem. According to the GUI, Unbound was not running - BUT the Internet via browser on the clients was working, so part of the DNS server must have been running. A reboot of OPNSense seemed to have fixed the problem - but I'll have to wait and see tomorrow.

OPNSense B:
Update and direct reboot
- A device can no longer connect to its cloud server.
I can address the device within my internal network (several VLANs routed via OPNSense), so the routing must basically work
- Internet access on my test client worked, websites could be loaded
- a "ping google.de" on the same test client shows no connection
- a "tracert google.de" stops at the OPNSense
- DNS worked, as both of the above commands were able to resolve an IP. I tried it with 3 different hosts, always the same behavior
- a restart of Unbound brought no change
- I checked to see if there was another update available on the OPNSense - the update routine could not connect to the update server either
After rebooting the OPNSense, everything seemed to work again (device had cloud connection, ping worked again, tracert worked again) - I did no other changes!

P.S. My Wireguard worked at least after the second reboot, before that I don't know.

Both OPNSense machines have been running for several years, nothing was changed in the configurations before the update. So it seems that something is sporadically unstable.

Dear all,
I'm pretty new to crowdsec and have a little question.

I setup crowdsec on opnsense and I think it works as it should.

Now I have some internal servers which are connected via port-forwarding in opnsense to the internet (either port-forwarding or HAProxy reverse proxy on opnsense).

What do I need to collect and analyze the log files of these dedicated servers and report it to crowdsec running on my opnsense? The blocking-rules should also happens on opnsense because this is the gatekeeper to the internet.

Are there any manuals out there for this scenario?

Thanks a lot

Dear Patrick,

thanks a lot for your answer.

Formerly I had interfaces per OpenVPN Instance just for better overview in firewall rules because I could define the rules on every interface instead have a lot of rules on the general OpenVPN Interface.

Like mentioned in this post https://forum.opnsense.org/index.php?topic=23460.msg112055#msg112055 I deleted all my sub-interfaces because it seems that it isn't desgined for subinterfaces.

After reading of the tutorial of wireguard I'm very confused which is the gold-standard.

So could you proof that it is okay to use subinterfaces on all VPN-Methods (wireguard as well as OpenVPN) without getting problems?

A little second question - OpenVPN as well as wireguard use transport-subnets which are only visible internally. When defining firewall-rules can I use the normal source and target of IP packets or do I have to filter the encapsulated transport-packages without knowing how it is translated into this transport-subnet.

Dear all,

is this question too difficult to answer?

I could not find any information in the documentation what the developers thought and how the basic configuration should be.
I also don't understand why individual interfaces are recommended for Wireguard and apparently not for other VPN technologies.

I would be very happy if someone from the core team would post a short answer.