Messages

Interface statistics widget while pretty and colourfull pie chart it is useless. You need to hover over the sections to see statistics, in smaller forms does not even show which interface is which colour.
The update may be progressive from the point of coding the widgets and usage of the router resources but from standpoint of actual usefulness it is a huge downgrade.
Another problem is that current dashboard is sluggish, I experience hiccups that take 3-5 seconds from time to time. I don't think this is ready to put into a release.

Hi everyone!
I have done upgrade to the OPNsense 24.1.1-amd64 and I noticed some problems with Wireguard VPN service:

• Peer setup interface is blocking adding peer with the same public key - this is new problem with 24.1.1
• Wireguard widget and diagnostic page shows wrong peer for service instance. In my example it shows the same peer for two wg instances wg1 and wg3 even though they are configured for different peers. This problem started somewhere in earlier OPNsense version
• When changing peer for wg instance, routing is sometimes stuck with old peer even after instance restart and whole wg service restart. Only full reboot fixes the problem. This problem was present for a while, would need to test more the newest release.

Why this is problematic? Well in the case of the first issue, it prevents me from adding more peers endpoints for vpn service as in my case they all have the same public key. This also prevents modification of existing peers, so for now I have not found any workaround (I don't really want to remove existing peers and be left with just one).

Second problem is for most parts just cosmetic but it shows that there is some issue with diagnostic page and Wireguard widget.

Last issue can be really annoying when trying to change peer endpoint for wg instance. It really would be great if changing peer did refresh routing.

For now the most pressing issue for me is the inability to add peers with the same public key in wg peer setup. If anyone can suggest some workaround or fix I would be really greatful.

Best regards.

Hi everyone,
I have multiwan setup and wireguard vpn up and running and would like to disable failover for wireguard only.
What I have:

• WAN1 - main connection
• WAN2 - backup connection
• wg0 - outbound vpn for several lan clients
• wg1 - inbound vpn for several remote clients

I think there are some problems with failover recovery with 23.1 but even without those I would rather have vpn bound to WAN1. I am fine with those dropping during WAN1 outage.

I have found https://forum.opnsense.org/index.php?topic=26315.msg127113#msg127113:

Can you try floating rules, source WAN address, source port wg, Gateway WAN, outbound direction. Same for WAN2. I think the validation was removed some time ago

But I seem to not be able to set any source port when creating Floating rule. Am I missing something? Is this the correct way to set it up or should I try something else?

Thanks in advance.

I am really not sure if this issue is affecting me but symptoms do look like it can.

I have WAN1 and WAN2, with multiwan failover and vpn network that should be routed only through WAN1.
What I observed was really flaky VPN behaviour after update to 23.1. I tried to diagnose it but I have not really change anything from last 22.7 version and it was rock solid before the update (Wireguard).

I assume the problem flow would be something like that:

• Failover  from WAN1 to WAN2.
• Some time when routing is still working.
• WAN2 fails.
• Routing is stuck with WAN2 (conjecture).
• I notice problems with VPN connections
• Gateway monitoring shows the same status for VPN gateway and WAN2 (packetloss/red/dead).
• Restaring VPN does not help, sometimes changing wg peer helps but flakes out really quickly.
• I need to reboot opnsense box.

From what I remember, when I configured VPN it should really only use WAN1 connection and in case of failover to WAN2 just die. I am not sure it ever worked that way but before current version (23.1) I have never had such issues.

This behaviour is persisting since my update to 23.1, so since few days after it went up for download. I did not do clean install, I updated through web interface.

So I am stuck rebooting the router every few days.

It is upstream issue:
https://github.com/sivel/speedtest-cli/pull/769

Hello everyone,
I am experiencing intermittent network connection drops. At first I was thinking it was my multi WAN failover setup doing some strange things but after few test runs with unplugging failover WAN connection I could not replicate the issue.

After scouring the forum for similar case I found one:
https://forum.opnsense.org/index.php?topic=22086.0

But the difference is that my hardware does not use Realtek based cards. I am using Shuttle barebone with:

• I211 Gigabit Network card on motherboards reported as I211 card
• 4 port INTEL PRO 1000VT on PCI-E reported as 82576 Gigabit Network Connection

Code Select Expand

OPNsense 21.1.4-amd64
FreeBSD 12.1-RELEASE-p15-HBSD
OpenSSL 1.1.1k 25 Mar 2021


Ping log from another machine:

Code Select Expand

2021-04-15 00:18:38 8.8.8.8 : [22980], 64 bytes, 62.0 ms (57.7 avg, 0% loss)
2021-04-15 00:18:48 8.8.8.8 : [22981], 64 bytes, 62.0 ms (57.7 avg, 0% loss)
2021-04-15 00:18:58 8.8.8.8 : [22982], 64 bytes, 61.6 ms (57.7 avg, 0% loss)
2021-04-15 00:19:09 8.8.8.8 : [22983], timed out (57.7 avg, 0% loss)
2021-04-15 00:19:19 8.8.8.8 : [22984], timed out (57.7 avg, 0% loss)
2021-04-15 00:19:29 8.8.8.8 : [22985], timed out (57.7 avg, 0% loss)
2021-04-15 00:19:39 8.8.8.8 : [22986], timed out (57.7 avg, 0% loss)
2021-04-15 00:19:49 8.8.8.8 : [22987], timed out (57.7 avg, 0% loss)
2021-04-15 00:19:59 8.8.8.8 : [22988], timed out (57.7 avg, 0% loss)
2021-04-15 00:20:09 8.8.8.8 : [22989], timed out (57.7 avg, 0% loss)
2021-04-15 00:20:19 8.8.8.8 : [22990], timed out (57.7 avg, 0% loss)
2021-04-15 00:20:29 8.8.8.8 : [22991], timed out (57.7 avg, 0% loss)
2021-04-15 00:20:39 8.8.8.8 : [22992], timed out (57.7 avg, 0% loss)
2021-04-15 00:20:49 8.8.8.8 : [22993], timed out (57.7 avg, 0% loss)
2021-04-15 00:20:59 8.8.8.8 : [22994], timed out (57.7 avg, 0% loss)
2021-04-15 00:21:09 8.8.8.8 : [22995], timed out (57.7 avg, 0% loss)
2021-04-15 00:21:19 8.8.8.8 : [22996], timed out (57.7 avg, 0% loss)
2021-04-15 00:21:29 8.8.8.8 : [22997], timed out (57.7 avg, 0% loss)
2021-04-15 00:21:39 8.8.8.8 : [22998], timed out (57.7 avg, 0% loss)
2021-04-15 00:21:49 8.8.8.8 : [22999], timed out (57.7 avg, 0% loss)
2021-04-15 00:21:59 8.8.8.8 : [23000], timed out (57.7 avg, 0% loss)
2021-04-15 00:22:09 8.8.8.8 : [23001], 64 bytes, 54.1 ms (57.7 avg, 0% loss)
2021-04-15 00:22:19 8.8.8.8 : [23002], 64 bytes, 52.9 ms (57.7 avg, 0% loss)
2021-04-15 00:22:29 8.8.8.8 : [23003], 64 bytes, 51.9 ms (57.7 avg, 0% loss)
2021-04-15 00:22:39 8.8.8.8 : [23004], 64 bytes, 53.5 ms (57.7 avg, 0% loss)


General log

Code Select Expand


2021-04-14T22:52:31 configctl[26362] event @ 1618433550.50 exec: system event config_changed
2021-04-15T00:19:24 kernel pflog0: promiscuous mode disabled
2021-04-15T00:19:24 kernel pflog0: promiscuous mode enabled
2021-04-15T00:23:06 kernel pflog0: promiscuous mode disabled
2021-04-15T00:23:06 kernel pflog0: promiscuous mode enabled
2021-04-15T00:39:23 sshd[95206] Accepted publickey for [cut]
2021-04-15T00:48:04 kernel igb3: link state changed to DOWN
2021-04-15T00:48:04 opnsense[99928] /usr/local/etc/rc.linkup: DEVD Ethernet detached event for opt3
2021-04-15T00:48:04 dhclient[37819] connection closed
2021-04-15T00:48:04 dhclient[37819] exiting.

Backend log

Code Select Expand

2021-04-14T22:52:31 configd.py[98565] [d2f94373-bd62-4568-8ba9-7260118605c8] trigger config changed event2021-04-15T00:19:23 configd.py[98565] [32f40b91-58cb-477d-8639-feb052a6c508] Reloading filter
2021-04-15T00:19:24 configd.py[98565] [81fe5405-1866-43c4-95de-c731163efff4] generate template OPNsense/Filter
2021-04-15T00:19:24 configd.py[98565] generate template container OPNsense/Filter
2021-04-15T00:19:24 configd.py[98565] OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2021-04-15T00:19:24 configd.py[98565] OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2021-04-15T00:19:24 configd.py[98565] [b7390b54-6ad0-4b21-b6b2-0b07b91bb70e] refresh url table aliases
2021-04-15T00:19:24 configd.py[98565] [b9233996-cfdf-4933-a290-496eb8f89fbf] updating dyndns [cut]
2021-04-15T00:19:24 configd.py[98565] message b7390b54-6ad0-4b21-b6b2-0b07b91bb70e [filter.refresh_aliases] returned {"status": "ok"}
2021-04-15T00:23:06 configd.py[98565] [a82d9ef4-d7f5-4da0-8a41-33f421c65c8a] Reloading filter
2021-04-15T00:23:06 configd.py[98565] [872c4080-1f2e-4fdc-97eb-ab4682549533] generate template OPNsense/Filter
2021-04-15T00:23:06 configd.py[98565] generate template container OPNsense/Filter
2021-04-15T00:23:06 configd.py[98565] OPNsense/Filter generated //usr/local/etc/filter_tables.conf
2021-04-15T00:23:06 configd.py[98565] OPNsense/Filter generated //usr/local/etc/filter_geoip.conf
2021-04-15T00:23:06 configd.py[98565] [a47d9cd9-b9cd-4f99-a5ff-63eb71945bab] refresh url table aliases
2021-04-15T00:23:06 configd.py[98565] [01adcf42-85b0-4125-bd81-f94186a56fdd] updating dyndns [cut]
2021-04-15T00:23:07 configd.py[98565] message a47d9cd9-b9cd-4f99-a5ff-63eb71945bab [filter.refresh_aliases] returned {"status": "ok"}



After looking at the logs the issue seem similar in a way that there is "kernel   pflog0: promiscuous mode disabled" nearly at the same time I get connection loss.

Is there anything more that I could do to narrow issue down? I specifically went with Intel based card to avoid known Realtek drivers issues.

Apart from multi WAN  failover setup (followed avaiable tutorial) I have installed:

• os-acme-client not used
• os-clamav not used
• os-dyndns not used
• os-iperf
• os-smart
• os-upnp not used