Messages

I have an A&A fibre [CityFibre] as one of the links on an OPNsense box.

I set the PPPoE gateway to the allocated /32 [on VLAN  911 for CityFibre].

Then defined the /24 to the same physical interface and added the non-gateway addresses as virtual IP's.

HTH

My road-warrior VPNs are working again with 23.1.3

I am seeing the same behavior with Android phones.

In my case I have never needed to do anything on the OPNsense end. Resetting/restarting the phone brings the connection up again.

It seems to be more of a problem when the phone is more mobile. I have all my phones set to use cellular data for the connection (no WiFi at any time). They are also set to have the VPN always on and to route all traffic via the tunnel.

If you are getting call establishment then the SIP part of the process is working as expected.

The audio path would be carried over the ports configured for RTP.

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.