Topics

One of our older OPNsense devices appears to have a certificate issue and does not want to update.
The hardware is a DEC610 device that was purchased several years ago from applianceshop.eu and that is currently running OPNsense 21.7-amd64.
When I try to Check for updates it fails to fetch the files due to a certificate error.
The log box shows the following:

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 21.7 (amd64/OpenSSL) at Tue Jun  6 01:27:54 CEST 2017
Fetching changelog information, please wait... Certificate verification failed for /C=BE/O=GlobalSign nv-sa/CN=GlobalSign GCC R3 DV TLS CA 2020
7163985113088:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
fetch: https://pkg.opnsense.org/FreeBSD:12:amd64/21.7/sets/changelog.txz.sig: Authentication error
Updating OPNsense repository catalogue...
Certificate verification failed for /C=BE/O=GlobalSign nv-sa/CN=GlobalSign GCC R3 DV TLS CA 2020
2040999223296:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /C=BE/O=GlobalSign nv-sa/CN=GlobalSign GCC R3 DV TLS CA 2020
2040999223296:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /C=BE/O=GlobalSign nv-sa/CN=GlobalSign GCC R3 DV TLS CA 2020
2040999223296:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /C=BE/O=GlobalSign nv-sa/CN=GlobalSign GCC R3 DV TLS CA 2020
2040999223296:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /C=BE/O=GlobalSign nv-sa/CN=GlobalSign GCC R3 DV TLS CA 2020
2040999223296:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /C=BE/O=GlobalSign nv-sa/CN=GlobalSign GCC R3 DV TLS CA 2020
2040999223296:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
pkg: https://pkg.opnsense.org/FreeBSD:12:amd64/21.7/latest/meta.txz: Authentication error
repository OPNsense has no meta file, using default settings
Certificate verification failed for /C=BE/O=GlobalSign nv-sa/CN=GlobalSign GCC R3 DV TLS CA 2020
2040999223296:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /C=BE/O=GlobalSign nv-sa/CN=GlobalSign GCC R3 DV TLS CA 2020
2040999223296:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
Certificate verification failed for /C=BE/O=GlobalSign nv-sa/CN=GlobalSign GCC R3 DV TLS CA 2020
2040999223296:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1915:
pkg: https://pkg.opnsense.org/FreeBSD:12:amd64/21.7/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***

Does anyone have any idea how to fix this? (preferrably without travelling to this remote location)

Kind regards,
BertM

For a test environment I setup an OPNsense router and during the initial wizard, I configured static IP for the WAN interface.
Although WAN connection was OK, the apinger service was stopped and there was no way to get it started. Also after reboot or power-off/Power-on, there was no way to get the Gateway Monitoring Deamon to start.

The following procedure permanently solved the issue:

• In the web gui, go to System ==> Gateways ==> All and click the pencil button to edit the default gateway.
• Do not make any changes, just click the Save button.
• After that you can start the apinger service.
  Also after a reboot or power-up, the apinger service will now start automatically.

By the way, in retrospect I think this issue already existed in earlier versions of OPNsense.

Kind regards,
Bert

For a test environment, I setup an OPNsense router, and after running the initial wizard, I noticed that I did not have internet connection.
Looking into the issue, I found that the DHCP server in OPNsense did not handout a value for the default gateway.

Although for the DHCP server (according to help in the web gui) the default is to use the interface IP, this did not seem to work.
After entering the interface IP address in the Gateway Field, everything worked OK, The DHCP client did get a default gateway configured and was able to connect to the internet.
When I removed the gateway entry from the web gui again, the DHCP clients did not get a gateway again.

So, it appears to be mandatory to enter the gateway for the DHCP server in the web gui.

This means that either the helptext in the web gui needs to be changed, or the web gui has to be changed to automatically take the interface address for the gateway.

Note that this issue exists in version 17.7, regardsless if you install from OPNsense-17.7-OpenSSL-dvd-amd64.iso or from the OPNsense-17.7.5-OpenSSL-dvd-amd64.iso

Kind regards,
Bert

I just replaced one of our pfSense firewalls for an OPNsense 17.7.5, and while attempting to configure the Phase 1 authentication for Mobile IPsec, I am unable to enter the Peer ID. There are no fields in the form to enter it.
As a result, none of my mobile IPsec clients can connect.
I am unable to configure the Shrewsoft VPN Client without a local identity.

I know  that it used to be there, because I have an older OPNsense 17.7.5 box that started with version 16.1, and although the field for Peer Identifier is currently also missing in the config form, the entry still exists in the configuration file because I configured it in the past.

I know that a temporary solution would be to enter it manually in the configuration file like below where the Peer ID TAG is "PeerID":

<peerid_type>keyid tag</peerid_type>
<peerid_data>PeerID</peerid_data>

and then upload the config again.
The problem for me is that uploading the config will reboot the firewall, and I am only allowed to do that once a month during a 15 minite time window.

Anyone having some clever ideas?

We have a number of OPNsense instances running that, until recently, were running OPNsense 16.7.14_2.
They had not been updated to 17.1 because of some issues we had with Mobile IPSec connections.
After testing showed that these issues were solved in 17.7, I updated the first 5 of them to the latest version.

Obviously, SNMP has now changed to a plugin, so I installed the os-snmp plugin.
On all these OPNsense installations I noticed that the processor utilisation flat-lined to 100%, although performance did not seem to be influenced much.

This high processor utilisation went away in all cases when I unchecked the box for "Host Resources" on the Services:SNMP page.

Note that:

• The issue exists on all 5 OPNsense installations that I updated from 16.7.14_2 to 17.7.
• All OPNsense installations are virtual machines running on VMware ESXi 6.5.0.
• All OPNsense installations are configured with 1 CPU core, 1024MB memory, 8GB disk and 3 or 5 E1000 network cards.
• All OPNsense installations are running the plugins for os-vmware and os-snmp
• All VMware servers hardware are HP Proliant DL385p Gen8 with 2 AMD Opteron 6320 processors.

Anyone has any idea what's going on here?

Kind regards,
Bert

This morning I updated one of our firewalls to 17.1.
It is a virtual machine running on ESXi 6.0.

The first thing we noticed was an issue with SNMP. After the SNMP plugin was installed, CPU load was at 100%.
Disabling one of the SNMP options (the one that required MibII) solved that one.

However, later today we encountered the problem that mobile IPSec clients had problems.
Using Shrewsoft VPN client, they were able to establish the VPN tunnel. After playing around a bit, they noticed that, although they could PING the terminal server they wanted to connect, they could not establish the RDP session.
I played around with several settings, but to no avail.

Unfortunately, I did not make a snapshot before the update.
Because the matter was urgent, and time was running out, I deleted the firewall, installed a fresh one from the 16.7 ISO, and loaded a config I backed-up in December.
All is up-and-running again, so I am at least allowed to go home for the weekend, but.....

I would like to update to 16.7.14, but whenever I appempt to update, it wants to go to 17.1, and is the version  that caused the problem in the first place, so I don't want to go there.

Is there a way to update to 16.7.14, and not to 17.1?

Kind regards,
Bert

I am using OPNsense version 16.7.2.
With user authentication against a Microsoft AD, some things that already seem to be implemented simply don't work.
In addition, some functionality that makes our life a whole lot easier is not (yet?) there.

Let's start with what is already there.
First of all the basics are working, meaning that I am, for instance, able to let users open an IPsec VPN while validating with their AD user account.

But......any of the 'filtering' options don't work.
The first thing is the 'Search scope'. In the GUI, there is a drop-down box for the Level that allows you to search One level deep or in the entire Subtree of the AD.
No matter what you select here, you always search the entire subtree.

Second thing are the 'Authentication containers'.
This is a required entry, and you should enter an OU (or a semicolon-separated list of OU's) where you would search for user accounts.
No matter what you enter here (you can even enter 'BlaBla'), it will still search the entire AD for User accounts.

I have been playing around with the 'Extended Query', and that seems to work (at least as far as I tested).
For example, to only allow users that are member of a certain group, one could enter something like:

memberOf=CN=Some_Group,OU=Security Groups,OU=Some_OU,DC=DOMAIN,DC=TopDomain

This actually works, but it is not yet what we would like to see.
What would really make me cheer is the ability to validate users based on membership of an AD group (and in OPNsense asign privileges to these AD Groups without specifyling the user account itself) much in the same way as it is implemented in pfSense.

One other thing in the GUI is that going to System ==> Access ==> Settings and clicking Save and Test button will trigger the pop-up blocker.

Just drop me an e-mail if you need more info, want me to demonstrate the issues via TeamViewer, or want me to test something.

Kind regards,
Bert

[entire subtree]

In OPNsense 16.1.18, there thill is a number of issues with validating Microsoft AD users.
The most important of these issues are:

• Filtering based on OU does not work.
• Filtering based on AD Group membership cannot be configured

These things work OK in pfSense but not in OPNsense, and this prevents me from migrating from pfSense to OPNsense.
Let me explain how I use this in pfSense.
Our company has a dozen branch offices in several countries worldwide.
All branch offices have a Microsoft Domain Controller, connect to the internet via pfSense and are interconnected via IPsec VPN.
There are over 2000 users in the AD, and only a hand-full of them are allowed a road-warrior IPsec VPN to any of these offices.
Because I do not want the Windows Domain Administrators to mess around with the network devices, we defined a number of groups in the AD and users are allowed road-warrior VPN access to any of the offices, based on membership of these AD groups.
This way I do not need to configure individual users in the pfSense devices, just groups (and allow "User - VPN - IPsec xauth Dialin" privileges for the group), and the Windows Admins only need to add the users as a member of the AD group to allow them to use their AD account to open a road-warrior VPN.

How did I configure this in pfSense?

In the Servers config on pfSense, I entered the following in the config for the nearest Domain Controller:
In the seach scope I set the level to entire subtree and entered the proper Base DN.
In Authentication containers, I entered the OUs where the groups reside in the AD
In the bind credentials, I added a user account that was able to query the AD
Set User naming attibute to samAccountName
Set Group naming attribute to cn
Set Group member attribute to memberOf

In the Groups config I entered the groups names exactly as they are named in the AD, and assigned the proper privileges to the groups.

What is it that does not work in OPNsense?

1. Filtering based on OU does not work.
What I mean is that OPNsense does not honor the level setting in the search scope, and it also does not honor the setting in Authentication containers.
What should happen is that only accounts in the OUs that are entered in the Authentication containers should be able to validate.
However, it does not matter what you enter in the Authentication containers (you can even enter a non-existing OU), any AD user is able to validate.
Also the level setting in the Search scope does not seem to matter but, given the issue above, I am not able to really test that.
What should happen is that if the level is set to one level, only users in the defined containers should be able to validate, and when it is set to entire subtree all users in the defined OU and any OU below that should be able to validate.

2 Filtering based on AD Group membership cannot be configured
In the GUI, there are no fields where the Group naming attribute and the Group member attribute can be configured.
As a result, Access based on AD group membership cannot be configured.

[cd /var/logrm *.logexit]

We still had some pfSense small devices (SML20081D) laying around that we purchased from applianceshop.eu some time ago and decided to change them to OPNsense.
These devices initially had a 2G CF card that we replaced with a 8G card and wrote OPNsense-16.1.8-OpenSSL-nano-i386.img on it.
Obviously, the nano image uses only 4G, and divides this in two slices of 2G.

Booted the device, configured it, and attempted an update to OPNsense 16.1.12 via the web GUI.
That failed with the message that it had insufficient disk space.

To overcome this (at least for now), I connected my laptop running PuTTY to the serial port, logged-in and started a shell ( option 8 ).

To free-up some space, I removed log files and closed the shell.
cd /var/log
rm *.log
exit

Then I performed an Upgrade from console ( option 12 ) which succeeded.

So here are my questions:

• Will, in the future, a nano image be made available for 8G CF cards (split in two slices of 4G), so there is sufficient disk space?
• If 1 will not happen, would it be an idea to change the GUI to allow updates to be done in individual packages?

Kind regards,
Bert

[Sending Classless Static Routes to DHCP Clients from OPNsense.]

I am not sure if this is the right place to post it, but maybe other people can benefit from the info below.

Having a chat about classless static routing with a few former colleagues, I realized that for may people it is unclear how to configure DHCP server to send classless static routing to DHCP clients.

Here below there is a copy of a short write-up I made for them.

Sending Classless Static Routes to DHCP Clients from OPNsense.

• In the OPNsense Web GUI, go to Services ==> DHCP ==> Server and select the tab for the apropriate interface.
• Scroll down to "Additional BOOTP/DHCP Options" and click the "Advanced" button.
• Click the little Plus button to add an additional option.
• In the Number field, enter the option number 121 for the Classless Static Route Option.
• Select String in the Type field, because this option sends is a string of octets to the DHCP client.
• Enter the apropriate string value field. This value is a number of octets, represented as a hexadecimal number and separated by colons.

Understanding the value string.
The string is made of the netmask and network of the destination (destination descriptor) and the address of the router that forwards traffic to the destination.
All octets are entered as their hexadecimal value.
So for example, if we want to route traffic to 192.168.10.0/24 via a router at 192.168.5.10, the string would be made as follows:

|-- Destination Descriptor --|
Netmask bits,  Network address, Forwarding router address
   24             192.168.10.0      192.168.5.10
    |             _|   |   |         |   |  |  |
    |            |   __|   |         |   |  |  |
    |            |  |   ___|         |   |  |  |
    |            |  |  |   __________|   |  |  |
    |            |  |  |  |   ___________|  |  |
    |            |  |  |  |  |   ___________|  |
    |_________   |  |  |  |  |  |   ___________|
              |  |  |  |  |  |  |  |
Hex string:  18:C0:A8:0A:C0:A8:05:0A


Note that in the example above, the last octet of the network address is omitted.
This is because, according to RFC 3442, the descriptor of the destination is in compact format.
This means that the destination descriptor starts with one octet that represents the subnet mask, followed by only the significant octets of the destination network address.
Significant octets are all octets where at least one of the corresponding netmask bits is 1.

So for example if I wanted to route the complete private class-B address range via 192.168.5.10, this would look like:

Netmask bits,  Network address, Destination router address
   12             172.16.0.0      192.168.5.10
    |             _|   |           |   |  |  |
    |            |   __|           |   |  |  |
    |            |  |   ___________|   |  |  |
    |            |  |  |   ____________|  |  |
    |            |  |  |  |   ____________|  |
    |_________   |  |  |  |  |   ____________|
              |  |  |  |  |  |  |
Hex string:  0C:AC:10:C0:A8:05:0A

Should we want to send multiple Classless Static Routing entries to the DHCP client, we can simply concatenate the two strings with a colon in between.
So for example for the above two routing entries, this would look like:

18:C0:A8:0A:C0:A8:05:0A:0C:AC:10:C0:A8:05:0A

Kind regards,
Bert

After updating to 15.7.22, the rrd graphs are no longer there.
Is this intentional, or just an unfortunate mishap and will they come back?

Kind regards,
Bert

I am trying to write the OPNsense-15.7_LibreSSL-nano-i386.img to a 2Gb CompactFlash that came with a device (pfSense Small, SML20081D) that we purchased from applianceshop.eu some time ago.

It seems that the image is to large for the CF.
Using Win32 Disk Imager, it gives the error: "Not enough space on disk: Size 4001760 sectors Available: 3931200 sectors Sectorsize 512".

The issue exists both for OPNsense-15.7_LibreSSL-nano-i386.img and for OPNsense-15.7_OpenSSL-nano-i386.img

Are the images to large or is there something wrong with the CF?

Is there an easy way to shrink the size of the image?

Bert

Waar kan ik de laatste versie vinden?

Op de OPNsense site in in de announcements staat dat op 8 juli versie 15.7.1 is uitgekomen, en op 10 juli versie 15.7.2.
Maar op alle mirrors en op sourceforge staan deze versies nog niet.
Daar is alleen versie 15.7 van 2 juli te vinden.

Enig idee waar ik de laatste versie vandaan kan halen?

Groet,
Bert