Messages

I saw the same issue upgrading to 22.1.4 as I did when upgrading to  22.1.3.

Using the console to restore the previous night backup resolved the issue for me.

My issue does not appear to be configuration related.

Having run a Health check, and dealt with a couple of minor issues, Wireguard sessions would still not come up.

Downgrade OPNsense to 22.1.2_1  and all is working.

As there are no references to Wireguard in the 22.1.3 patch notes it looks like there is an unexpected dependence on one of the other changes.

@Superduke

Yes. I also tried firewall reboots and removing the plugin and reinstalling again.

@mimugmail

This does not appear to match my scenario, and the solution presented looks to differ from the Road Warrior Setup docs. I did try the suggested solution, but that did not resolve the problem.


Form the GUI the wireguard service  looks to be running in that I can see activity in the List Configuration tab, but no handshakes.

I am seeing a similar issue.

The only difference is that I updated to 22.1.3 a few days ago. os-wireguard version 1.10

Connections were working as of 2022-03-22 21:00 (GMT) but now there are no handshakes.

It looked like as handshakes expired they were not renewed and once all had expired that was it.

Is the implication here that this is failing because the VM does not have a real external IP?

I've just created a new VM and installed 22.1 from the iso and I see the same error from the CLI and the GUI.

Restoring the previous configuration still results in this error.

This is the state of the system having upgraded 21.7.7 to 21.7.8 to 22.1 via the GUI.

No user side changes were made.

Running OPNsense as a VM on Virtualbox 6.1

Post upgrade I'm unable to check for package updates.

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 22.1 (amd64/OpenSSL) at Tue Oct  6 10:11:06 BST 2189
Fetching changelog information, please wait... Certificate verification failed for /OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
34374492160:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1916:
fetch: https://pkg.opnsense.org/FreeBSD:13:amd64/22.1/sets/changelog.txz: Authentication error
Updating OPNsense repository catalogue...
Certificate verification failed for /OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
34378686464:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1916:
Certificate verification failed for /OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
34378686464:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1916:
Certificate verification failed for /OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
34378686464:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1916:
Certificate verification failed for /OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
34378686464:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1916:
Certificate verification failed for /OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
34378686464:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1916:
Certificate verification failed for /OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
34378686464:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1916:
pkg: https://pkg.opnsense.org/FreeBSD:13:amd64/22.1/latest/meta.txz: Authentication error
repository OPNsense has no meta file, using default settings
Certificate verification failed for /OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
34378686464:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1916:
Certificate verification failed for /OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
34378686464:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1916:
Certificate verification failed for /OU=GlobalSign Root CA - R3/O=GlobalSign/CN=GlobalSign
34378686464:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1916:
pkg: https://pkg.opnsense.org/FreeBSD:13:amd64/22.1/latest/packagesite.txz: Authentication error
Unable to update repository OPNsense
Error updating repositories!
pkg: Repository OPNsense cannot be opened. 'pkg update' required
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***

I have a /29 subnet on the WAN interface and tend to allocate services across the IP range.

In setting-up WireGuard I've found that when listening on any of the virtual IP's WireGuard will show peers connecting and traffic being received and sent from the firewall. But that the remote device never see's the response from the firewall and handshakes never occur.

Successful connections only occur when listening on the firewalls WAN IP address.

I could not find anything about this in the documentation and wondered if this is an inherent restriction for WireGuard, or is there a way to configure its use on a virtual IP?

Thanks

[ue0]

My fibre has been down for 18 days now so I am actually connecting via my mobile at the moment.

So the answer is yes. But it was not quite a case of working first time, and may also depend on what hardware you are running your firewall on. I'm using an HP Gen 10 Xeon box.

What worked for me was to put the phone into USB Tethering mode and to use the original USB cable supplied with the phone. Other USB cables did not work.

If recognised you should see a new interface, ue0 here,  which you can then assign and configure.

I have a floating rule that allows web (http/https) access.

I'm struggling to resolve why I see the follow allow/block messages in the logs.


LAN      Apr 28 21:04:19   192.168.1.100:45213   142.250.200.33:443   tcp   F: http/https [ALL]   
LAN      Apr 28 21:03:44   192.168.1.100:47727   34.232.16.1:443     tcp   F: http/https [ALL]   
LAN      Apr 28 21:03:44   192.168.1.100:53856   3.212.170.46:443   tcp   Default deny rule   
LAN      Apr 28 21:03:44   192.168.1.100:46893   142.250.200.1:443   tcp   Default deny rule   
LAN      Apr 28 21:03:44   192.168.1.100:53856   3.212.170.46:443   tcp   Default deny rule   
LAN      Apr 28 21:03:44   192.168.1.100:46893   142.250.200.1:443   tcp   Default deny rule

If you can help explain how I can fix this that would be great.

On my Linux workstations I am seeing the same behaviour with Firefox and Brave.

Using OPNsense 21.1.1-amd64

When creating filters there is no option to select an OpenVPN interface.

In my case ovpns1 or ovpns2 are listed as the interface for the log records but the filter drop-down does not include these as options.

Update:

I originally posted as the high CPU was seen before and after a firewall reboot.

Having closed the browser (Brave on Linux) for an extended period (> 60m)  CPU usage has returned to normal.

Running on an HP Gen 10 Xenon microserver the CPU usage has gone from 0-3% to 25-30% after the upgrade from 20.7.8 to 21.1

From System: Diagnostics: Activity the cause looks to be due to high lighttpd load:

WCPU
100.00%   /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf

WAN

xxx.xxx.xxx.248/29 public address range
xxx.xxx.xxx.249 - Firewall external address
xxx.xxx.xxx.250 - Firewall virtual IP
xxx.xxx.xxx.251 - Firewall virtual IP
xxx.xxx.xxx.252 - Firewall virtual IP
xxx.xxx.xxx.253 - Firewall virtual IP

xxx.xxx.xxx.254 - Gateway

LAN

yyy.yyy.yyy.1 - Firewall internal address
yyy.yyy.yyy.50 - Server internal address

NAT Outbound for yyy.yyy.yyy.50 to xxx.xxx.xxx.253

Running a trace route from yyy.yyy.yyy.50 to a distant server I see the initial hops as:

yyy.yyy.yyy.1
xxx.xxx.xxx.254
xxx.xxx.xxx.253
Then to the upstream ISP IP's

I'm surprised that the packets route to the gateway IP then to the virtual IP.

Is this expected or might I have miss-configured something?

Thanks