Topics

[The system is powering off now]

I've just tried to restart a firewall several times from the GUI. It returned to the GUI sometime later without restarting.

I then tried to power it off. The GUI remained at The system is powering off now but never powered off.

Watching the console via the iLO interface no activity was logged during this process.

I've had an issue with an OPNsense 23.7.5-amd64 firewall this morning.

2023-10-03T09:53:18   Informational   unbound    [74018:a] info: generate keytag query _ta-4f66. NULL IN
2023-10-03T09:53:15   Notice   unbound    daemonize unbound dhcpd watcher.
2023-10-03T09:53:14   Critical   unbound    [74018:1] fatal error: Could not initialize thread
2023-10-03T09:53:14   Informational   unbound    [74018:1] info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0
2023-10-03T09:53:14   Informational   unbound    [74018:0] info: start of service (unbound 1.18.0).
2023-10-03T09:53:14   Informational   unbound    [74018:1] info: server stats for thread 1: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting
2023-10-03T09:53:14   Error   unbound    [74018:1] error: Could not set root or stub hints
2023-10-03T09:53:14   Error   unbound    [74018:1] error: reading root hints /root.hints 2:9: Syntax error, could not parse the RR's type

I believe from the time the error was logged until the firewall was rebooted DNS requests were not answered.
It appeared that I could not start, stop or restart it from the GUI and CPU usage was 15x normal. Though I could later see a log record showing that Unbound was stopped.

Before it was rebooted I was able to ssh into the firewall and could see that there was a /var/unbound/root.hints  file with a newer timestamp (~12:00) and that the contents matched the root.hints from another firewall.

I was wondering if there is a better/cleaner way to recover from this scenario?

Before I consider upgrading to 23.7 I need to migrate 24 VPN's currently configured via Tunnel Settings to Connections [new] .

While I have already moved some of the OPNsense to OPNsense tunnels I have still to get a Draytek tunnel running.

They are all currently configured using the same template, so if I get get one running I'll be able to get the rest done.


Draytek configuration:

- Dial-out, Always on
- IKEv2
- PSK
- AES with authentication
- IKE Phase 1 aes256/sha256/dh14  [aes256-sha256-modp2048]
   I have also tried aes256/sha256/dh21 [aes256-sha256-ecp521]
- IKE Phase 2 aes256/sha256
- IKE phase 1 key lifetime 86400
- IKE phase 2 key lifetime 86400
- pfs enabled

I have also created and tested a Draytek profile that will handle dial-in and Dial-out to see if this would work.

The reason for the Dial-out setting is that a few of the Draytek sites have more than one subnet. If the OPNsense firewall originates the connection then only the primary subnet SA establishes. If the Draytek router originates the connection then all SA's establish.

As already noted in the forum, and when I migrated an OPNsense to OPNsense tunnel, the ESP rules were not automatically created. From watching the traffic I have created rules to cover ESP, ISAKMP and IPsec NAT-T.

One thing I am not sure about is that having created a Pre-Shared Key entry for the connection using an email addresses as the Local Identifier, that this email address is what is used in the Local Authentication Id field when Authentication is Pre-Shared Key (which is what I have used).

If anyone has managed to get a Connections [new] for Draytek router I would appreciate any tips.

I have no problem in getting the Site-to-Site traffic passing.

But I'm having limited success on doing the far-end break-out, currently it is working from A to B, but not B to A.

I have not found anything in the forum, so could someone point me to any documentation that might help?

Thank you.

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

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.

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.

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

For a policy-based IPSEC between 2 OPNsense 20.7.5 boxes I have NAT-T disabled.

In the logs I can see both sides sending data on UDP/4500 which, as expected, is block at the other end.

Are there other configuration settings which affect NAT-T outside of the phase 1 configuration?

I'm currently running   OPNsense 20.7.5  though I don't think the following behaviour is version specific.

I've been trying to track down the cause of an inter PBX issue for a while and have been restarting my upstream WAN gateway as part of the testing.

What I was not expecting is that shortly after the WAN link is restored I see sessions between my LAN and other local interfaces drop e.g ssh sessions between LAN and DMZ.

Does anyone know if this is the expected behaviour and what the root cause may be?

Thanks

I've migrated a couple of sites to OPNsense and they are both using LetsEncrypt certificates.

I've been trying to get a point-to-point IPSEC link running using Mutual RSA which looks to be nearly, but not quite,  there.

I've tried quite a few combinations of settings, but thought it would be worth asking if any has already done this and if so how?

Thanks

M