Messages

Thanks Franco,

Cool, I did not realize that there were still some HTTP mirrors.
Selecting a HTTP mirror did indeed allow me to update to the latest version although during each check for updates, it failed authentication while fetching the changelog.txz.
I had hoped that updating would also solve the certifivate issue, but it did not.
See below the check for update after updating to the latest version while still having a HPPT mirror selected.

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 22.1.5 (amd64/OpenSSL) at Wed Jun  7 00:49:12 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
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...
Fetching meta.conf: . done
Fetching packagesite.txz: .......... done
Processing entries: .......... done
OPNsense repository update completed. 785 packages processed.
All repositories are up to date.
Checking integrity... done (0 conflicting)
Your packages are up to date.
Checking for upgrades (0 candidates): . done
Processing candidates (0 candidates): . done
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***

Is there an easy way to solve this certificate issue, or should we just re-install OPNsense software from scratch if/when someone from IT is on site?

Kind regards,
Bert

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

Mastermind,

If I understand correctly, you have multiple internal web servers each serving a number of sites that are addressed by their URL, and your provider does not allow multiple IP adresses on the same physical nic.

Although it is outside the scope of OPNsense, I would go for another solution.

Considering the fact that you are already virtualizing things anyway, it should not be a problem to add a small linux box to use as a reversed proxy.
Than, you can configure OPNsense to forward ports 80 and 443 to the reversed proxy, and let the proxy send the requested URL's to the proper server.

I am doing something similar where I use 1 public IP for 48 URL's, that are port forwarded to an Ubuntu server running apache, used as a reversed proxy. The Ubuntu box forwards this traffic to 9 different servers.

For me this works flawlessly.

kind regards,
Bert

Franco,

For now after each update in the 17.7 series, to be able to configure the peer ID for mobile IPsec clients, I issued the command "opnsense-patch 0dd120".

The important questions for mwe are:

• Will this be fixed in the 18.1 series?
• If not, will running the command "opnsense-patch 0dd120" still fix things for me?

Kind regards,
Bert

FarmServer,

What you see (UDP packets towards 255.255.255.255:68) is a DHCP discover from a device that does not yet have an IP address (hence the 0.0.0.0 source adrress) and is trying to find a DHCP server to request an address.
For some reason, this DHCP discover is relayed (from your ISP network?) to your OPNsense box.

Kind regards,
Bert

jl_678

No need to use internal DNS server.
The trick is to use NAT reflection in your port forwarding config.

See description in this post:
https://forum.opnsense.org/index.php?topic=6155

Kind regards,
Bert

ddqloo

You should change the port for the webgui if you intend to forward port 443.
A good description of portforwarding port 80 and 443 can be found in this topic:
https://forum.opnsense.org/index.php?topic=6356.0

@ChrisH: The web gui can be accessed via any interface of the OPNsense, provided firewall rules allow you in. That is why you want to change the port for the web gui. If you don't do that, WAN port 443 will be in use for the web gui.

@hutiucip: The anti-lockout rule is just there to prevent you accidentally lock yourself out of the web gui by blocking the port that the web gui listens on. That is why the anti lockout rule always allows the port for the web gui from the LAN interface.

Kind regards,
Bert

Healthy65,

OPNsense does not catch UDP port 53 unless it is specifically targeted at the OPNsense address.
This means that computers in your lan will use whatever DNS server they are configured to use.

Now about DHCP.
Let's assume Dnsmasq DNS forwarder or Unbound DNS resolver is enabled and no DNS server addresses are configured in the DHCP service or Static ARP for specific clients.
In this case, the DHCP clients get the IP address of the OPNsense interface configured as DNS server, and any DNS queries will be handeled by Dnsmasq or Unbound.

The difference between Dnsmasq and Unbound is that Dnsmasq will forward all DNS queries to the upstream DNS servers (the ones that are configured at System ==> Settings ==> General), and not cache the result, while Unbound will also query the upstream DNS servers just like DNSmasq, but will also store the result in local cache for faster serving subsequent similar queries.

If any DNS servers are configured in the DHCP configuration, this will override the default and the DHCP clients will get the DNS servers configured as they are in the DHCP server config.

If any DNS servers are configured in any static ARP entries, this will override the default as well as the settings in DHCP server and the DHCP clients that are specified by the ARP entries will get the DNS servers configured as they are configured in the static ARP entries.

Kind regards,
Bert

Julien,

I am not sure what you want to accomplish but, reading your story, I guess you have 4 IP addresses on your WAN interface, and you want to forward port 443 from some of these external addresses to different web servers.

If you want to forward port 443 from any of the WAN addresses to anywhere, the first thng to do (to avoid conflicts) is to change the port for OPNsense management to another port. (Go to System ==> Settings ==> Administration and enter a different port in the TCP port field.)

Next, you can enter a NAT port forward rule for every address from where you want to forward port 443.
So, for example:

WAN interface address 1.1.1.1 port 443 to Internal Webserver1 port 443
WAN interface address 1.1.1.2 port 443 to Internal Webserver2 port 443
WAN interface address 1.1.1.3 port 443 to Internal Webserver3 port 443
WAN interface address 1.1.1.4 port 443 to Internal Webserver4 port 443

On the other hand, if you have so many web servers, why not address them by URL to one single external IP address and use a reversed proxy to send things to the proper server? I do something like that for something like  25  websites on 8 servers.
Just a thought.

Kind regards,
Bert

weust,

I have no experience at all with the Q-Logic cards.
When I run OPNsense under VMware, I mostly do that on HP Proliant hardware with the following network cards:

• Broadcom NetXtreme BCM5719
• Broadcom NC382i Integrated Multi Port PCI Express
• Intel I350
• Intel 82571EB

In two cases, for desaster recovery purposes, I have been running OPNsense in VMware on Apple Mac Mini server, using both the internal Broadcom NetXtreme BCM57766 and the Thunderbolt connected Broadcom NetXtreme BCM57762

So at least I know that these cards work OK.

Kind regards,
Bert

Hi BCCHowdy,

It does indeed sound like a autonegotiation/duplex mismatch issue.
A nice explanation that can help you better understand this can found at
https://www.appliedtrust.com/resources/performance/untangling-ethernet-performance-problems

Kind regards,
Bert

Could it be that the SkyQ Set Top Box requires some ports to be forwarded to it?

Hi dragon2611,

If I understand correctly, you are trying to create a port forward rule for all available ports.
I think it is a good thing that OPNsense does not allow you to configure this, because it would make your firewall useless.

So what is it that you are trying to accomplish?
You want to send any traffic that comes in on your WAN interface to a specific address on your LAN?

In that case you could try a NAT One-to-One rule.

But would it not be better just to forward the ports you need?

Kind regards,
Bert

tuaris,

You need to add a phase2 entry for all traffic that need to pass to the other side.
You already made two phase2 entries, one connecting 192.168.7.0/24 to 192.168.0.0/24, and one connecting 10.9.9.0/24 to 10.8.8.0/24.
You just need to add a third phase2 entry connecting 192.168.0.0/24 to 10.9.9.0/24

Kind regards,
Bert

Vince,

The only time I ever encountered something like that was when I misconfigured firewall rules for IPsec on one side.

Maybe you also have something wrong with Firewall Rules?

Kind regards,
Bert