Topics

1

24.1 Legacy Series / Wireguard - Peer Generator

« on: April 11, 2024, 12:51:42 pm »

Would it be worth adding a DNS field to VPN: Wireguard: Peer Generator?

It may resolve an issue where people are configuring road warriors, which can't resolve DNS, which looks to be a common question.

Edit: And possibly an IP address field.

2

24.1 Legacy Series / Kea testing observations

« on: March 06, 2024, 11:45:10 am »

I've migrated a couple of firewalls to see how Kea behaves. Both have multiple networks which are using DHCP.  Both migrations were seamless and Kea is working as expected.

Some of the things I experienced I think could be enhanced if they are possible to deploy.

- When creating a subnet I would find it useful to be able to also define a name/label, or pull-in the interface name for the subnet (from a readability perspective).

- When creating a subnet you can enter a pool (as a /29 in my test) which is not in the subnet.

- When creating a reservation there is a check that the IP address is in the displayed subnet. As all the subnets are already defined this could be reversed such that the subnet is set from the entered IP address. Which is another way of saying I frequently did not have the right subnet when manually migrating reservations. That may have also been less of an issue if the subnet selection was name based rather than IP address based.


For the log file

- I miss seeing the DHCP discover, offer, etc. messages.

- ISC DHCPv4 will log a hostname if available, I've not seen them in the Kea logs yet.

While neither of the log messages are required they make it easier to spot a new device trying to connect to a network and if there is an issue with it.

3

23.7 Legacy Series / Unbound - error: reading root hints

« on: October 03, 2023, 06:50:13 pm »

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?

4

Virtual private networks / IPsec migrating to Connections [new] for Draytek 286x routers

« on: August 29, 2023, 01:37:43 pm »

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.

5

Virtual private networks / WireGuard Site-to-Site Setup with far-end break-out

« on: June 30, 2023, 01:45:53 am »

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.

6

22.1 Legacy Series / post upgrade updates fail with Certificate verification failure.

« on: January 30, 2022, 12:52:06 pm »

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***

7

21.7 Legacy Series / WireGuard - configuration using virtual WAN IP's

« on: December 24, 2021, 11:27:15 am »

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

8

21.1 Legacy Series / Log confusion

« on: April 29, 2021, 12:23:07 pm »

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.

9

21.1 Legacy Series / Firewall: Log Files: Live View OpenVPN interface

« on: February 10, 2021, 07:28:45 pm »

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.

10

21.1 Legacy Series / High CPU usage after upgrade.

« on: January 31, 2021, 11:21:30 am »

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

11

20.7 Legacy Series / routing when using WAN virtual IP's

« on: December 06, 2020, 05:15:18 pm »

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

12

Virtual private networks / IPSEC (NAT-T)

« on: November 27, 2020, 11:27:41 am »

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?

13

20.7 Legacy Series / unexpected behaviour on restore of wan link.

« on: November 26, 2020, 07:12:48 pm »

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

14

General Discussion / IPSEC Mutual RSA with LetsEncrypt certificates

« on: July 06, 2020, 06:54:08 pm »

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