Messages

Tested successfully in 21.7.2

Cheers!

I think the unbound GUI in opnsense should allow for entries without a domain. Unbound supports it (just add a line "local-data: "hostname A 10.1.1.1") and I think it's common for people to use it without.

Sorry, did a few more tests and realized I gave an incorrect information: the reason the problem doesnt manifest in my test server is that it installed with openssl by default. If I switch it to libressl I see the problem, so it's all clear now, my test had an additional variable I didnt factor in.

Cheers

Thanks for the quick response, Franco

Just for sanity check

1) The fix pointed is in the CSR function, but the issue happened for signing an uploaded CSR but also for creating a certificate inside opnsense (or create a CA certificate in system_camanager.php). Is this fix working for all cases?

2) I dont have the issue if I load my backup data into a new 21.7.1 and I also dont have the issue if I use a vanilla 21.7.1 with no past certificate data inside. I only have the issue in this box that has a few of CA, server and client certs loaded. Is the issue happening only with certain legacy data? It's not clear for me why the two other tests (empty new box and box loaded with restored config from the affected one) dont manifest the issue.

Anyways, when I update to 21.7.2 I will report back and hopefully it will be alright.

PS: original box has libressl, while test box is openssl, so explains the difference

Here is some additional info:

- If I use backup/restore to copy all my CA and certs to a new 21.7 server I dont have any issues, so I dont know if the issue is because there is some cert that opnsense doesnt like, it seems there is something related to the migration itself
- The issue happens in the cert and ca pages identically (system_certmanager.php and system_camanager.php)
- I captured the output of /tmp/php-fastcgi.socket-1 using socat and formatted a bit:

# mv /tmp/php-fastcgi.socket-1 /tmp/php-fastcgi.socket-1.original
# socat -t100 -x -v UNIX-LISTEN:/tmp/php-fastcgi.socket-1,mode=777,reuseaddr,fork UNIX-CONNECT:/tmp/php-fastcgi.socket-1.original

CONTENT_LENGTH769..
QUERY_STRINGact=new..
REQUEST_URI/system_certmanager.php?act=new..
REDIRECT_STATUS200..
SCRIPT_NAME/system_certmanager.php.
%SCRIPT_FILENAME/usr/local/www/system_certmanager.php..
DOCUMENT_ROOT/usr/local/www/..
REQUEST_METHODPOST..
SERVER_PROTOCOLHTTP/2.0..
SERVER_SOFTWAREOPNsense..
GATEWAY_INTERFACECGI/1.1..
REQUEST_SCHEMEhttps..
HTTPSon..
SERVER_PORT8443..
SERVER_ADDR192.168.71.1..
SERVER_NAME192.168.71.1..
REMOTE_ADDR192.168.71.31..
REMOTE_PORT50181..
HTTP_HOST192.168.71.1:8443.NHTTP_USER_AGENTMozilla/5.0 (Windows NT 10.0;Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0.J
HTTP_ACCEPTtext/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8..
HTTP_ACCEPT_LANGUAGEen-US,en;q=0.5..
HTTP_ACCEPT_ENCODINGgzip, deflate,br.8
HTTP_REFERERhttps://192.168.71.1:8443/system_certmanager.php?act=new.!
CONTENT_TYPEapplication/x-www-form-urlencoded..
HTTP_CONTENT_LENGTH769..
HTTP_ORIGINhttps://192.168.71.1:8443..
HTTP_DNT1.*
HTTP_COOKIEPHPSESSID=51027052befe7f78c6b18af86b16de76..
HTTP_UPGRADE_INSECURE_REQUESTS1..
HTTP_SEC_FETCH_DESTdocument..
HTTP_SEC_FETCH_MODEnavigate..
HTTP_SEC_FETCH_SITEsame-origin..
HTTP_SEC_FETCH_USER?1..
HTTP_TEtrailers..
SSL_PROTOCOLTLSv1.3..
SSL_CIPHERAEAD-AES128-GCM-SHA256..
SSL_CIPHER_USEKEYSIZE128..
SSL_CIPHER_ALGKEYSIZE128................

czYyNGZkNmxmTEtmczZuNzdFOXFzQT09=a2swN3VnNUN4Sy8vNlRpRHlxRU43dz09&act=new&certmethod=internal&descr=cert1&cert=&key=&caref_sign_csr=5bd829f3c5f92&digest_alg_sign_csr=sha256&lifetime_sign_cs
r=397&csr=&basic_constraints_path_len_sign_csr=&caref=5bd829f3c5f92&cert_type=usr_cert&keytype=RSA&keylen=2048&curve=prime256v1&digest_alg=sha256&lifetime=397&private_key_location=firewall&
dn_country=XX&dn_state=XX&dn_city=XX&dn_organization=UKI+SE&dn_email=ca-ovpn%40mail&dn_commonname=cert1&altname_type%5B%5D=DNS&altname_value%5B%5D=&csr_keytype=RSA&csr_keylen=204
8&csr_curve=prime256v1&csr_digest_alg=sha256&csr_dn_country=AD&csr_dn_state=&csr_dn_city=&csr_dn_organization=&csr_dn_organizationalunit=&csr_dn_email=&csr_dn_commonname=&certref=5a056c8779
f73&save=Save........


- It matches with the data I collect from the browser:


* Request headers

POST /system_certmanager.php?act=new HTTP/2
Host: 192.168.71.1:8443
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://192.168.71.1:8443/system_certmanager.php?act=new
Content-Type: application/x-www-form-urlencoded
Content-Length: 770
Origin: https://192.168.71.1:8443
DNT: 1
Connection: keep-alive
Cookie: PHPSESSID=51027052befe7f78c6b18af86b16de76
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
TE: trailers


* Request URL

https://192.168.71.1:8443/system_certmanager.php?act=new


* Request POST content

czYyNGZkNmxmTEtmczZuNzdFOXFzQT09=a2swN3VnNUN4Sy8vNlRpRHlxRU43dz09
act=new
certmethod=internal
descr=dasdsasa
cert
key
caref_sign_csr=5bd829f3c5f92
digest_alg_sign_csr=sha256
lifetime_sign_csr=397
csr
basic_constraints_path_len_sign_csr
caref=5bd829f3c5f92
cert_type=usr_cert
keytype=RSA
keylen=2048
curve=prime256v1
digest_alg=sha256
lifetime=397
private_key_location=firewall
dn_country=XX
dn_state=XX
dn_city=XX
dn_organization=XX
dn_email=ca-ovpn@mail
dn_commonname=dsa
altname_type[]=DNS
altname_value[]
csr_keytype=RSA
csr_keylen=2048
csr_curve=prime256v1
csr_digest_alg=sha256
csr_dn_country=AD
csr_dn_state
csr_dn_city
csr_dn_organization
csr_dn_organizationalunit
csr_dn_email
csr_dn_commonname
certref=5a056c8779f73
save=Save


* Response headers

HTTP/2 500 Internal Server Error
content-type: text/html
content-length: 365
date: Tue, 10 Aug 2021 17:23:00 GMT
server: OPNsense
X-Firefox-Spdy: h2

Hi guys

I've updated today from 20.X to the latest 21.7 and the pages for trust in the web GUI are giving me a 500 error. It does that if I try to create a new certificate in OPN or if It ry to make it sign a CSR.

In lighttpd.log I see:

Aug  9 16:07:02 firewall lighttpd[38170]: (mod_fastcgi.c.419) unexpected end-of-file (perhaps the fastcgi process died):pid: 55793 socket: unix:/tmp/php-fastcgi.socket-1
Aug  9 16:07:02 firewal lighttpd[38170]: (gw_backend.c.2275) response not received, request sent: 2098 on socket: unix:/tmp/php-fastcgi.socket-1 for /system_certmanager.php?act=new, clo
sing connection
Aug  9 16:08:31 firewall lighttpd[38170]: (mod_fastcgi.c.419) unexpected end-of-file (perhaps the fastcgi process died):pid: 55793 socket: unix:/tmp/php-fastcgi.socket-1
Aug  9 16:08:31 firewall lighttpd[38170]: (gw_backend.c.2275) response not received, request sent: 2098 on socket: unix:/tmp/php-fastcgi.socket-1 for /system_certmanager.php?act=new, clo
sing connection
Aug  9 16:10:27 firewall lighttpd[38170]: (mod_fastcgi.c.419) unexpected end-of-file (perhaps the fastcgi process died):pid: 55793 socket: unix:/tmp/php-fastcgi.socket-1
Aug  9 16:10:27 firewall lighttpd[38170]: (gw_backend.c.2275) response not received, request sent: 2098 on socket: unix:/tmp/php-fastcgi.socket-1 for /system_certmanager.php?act=new, clo
sing connection

In the browser (tried both latest chrome and firefox, same error):


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <title>500 Internal Server Error</title>
</head>
<body>
  <h1>500 Internal Server Error</h1>
</body>
</html>


The version is:

Versions    OPNsense 21.7.1-amd64
FreeBSD 12.1-RELEASE-p19-HBSD
LibreSSL 3.3.3



I have another firewall in the exact same version and went there to create a cert and it created just fine, so I believe this has something to do with the particular data or "state" in this firewall.

The reason I had to go create a certificate jsut now is that I noticed with the new openvpn version it doesnt like certificates that have a space in the beginning of the CN, they stopped working after I updated OPNsense to 21.7 from 20.X but I dont think the presence of certs like that are causing the UI to have the error 500 because in my 2nd test firewall I can create certs before and after creating a certificate with a space in the beginning of the CN field.

What could I do to get more info on this? From the timestamp the other files in /var/log dont seem to relate to the webserver. Is there a "debug mode" or something?

As a workaround for now I downloaded the CA data and issued a certificate externally and it's working with openvpn

Thanks

I found the solution, this was driving me crazy. Indeed the opnsense in router mode between the 2 subnets is not passing the broadcast. One of the ESX servers has 4 NICs and the first was connected to network1 and has an IP configured. Someone connected another NIC to a switch in network2. Now even if the 2nd NIC has no IP and was not configured, the DHCP broadcasts from the VMs were being broadcasted in both NICs, causing the VMs in this ESX to get IPs from both DHCPs. Simply disabling the 2nd NIC in the ESX stopped the madness (until I can ask someone to go there and disconnect the cable).

Hello community

I have a network setup in which I have 1 OPNSense as a NAT and another OPNSense as a router (no NAT) to another internal subnet. Like this:

internet --- OPN1-NAT--- SubnetC1 --- OPN2-NON_NAT --- SubnetC2

Both OPNSense have DHCP servers running in the internal LAN interface only (OPN1 should serve a range in subnetC1 and OPN2 serves a range in SubnetC2

The problem I have is that sometimes the machines in C1 gets and IP from C2 and vice versa.

Is there a way I can configure the filtering to avoid this from happening?

Thanks

Hello opnsense community

I have had a weird issue twice with two different opnsense versions (17.7.8 and 18.1.6). I tried to search the issue in freebsd and I couldn't finnd anything similar. So please bear with me

I have a VM with OPNsense over a VMWare ESX 5.5 (on an old Xeon machine, old enough to not have AES NI capabilities). This machine is configured as a firewall/NAT/openvpn with two interfaces and runs some additional services. The VMWare only runs two VMs and is not overloaded by any means (and when the issue happens I dont see anything weird in resource usage in the other VM). The OPNsense has plenty of resources (4GB of RAM, one vCPU, 40GB of disk space with less than 10% of disk space used).

Now here is the issue that it happened twice: one day with no warning connectivity starts to get very slow. I know this cold be said to be an external problem, but no indications that this is the case. It gets slow for people using any resource (openvpn, ssh, nat), I tried for example to copy logs to a machine in the LAN and also to a machine in the WAN side (internet) and the scp just slows to a halt. At the same time the graphs indicates high latency, I have disconnections and in the system graphs (CPU, mem), there are long sections without records (as if the machine was completely unresponsive for 5 to 10 minutes), this happened several times until I decided to reboot. So sometimes it simply gets completely unresponsive or when it's responsive all traffic is very slow.

In the ESX logs or esxtop nothing indicates an overload of resources or any other issue that could explain the unresponsiveness. In the dmesg logs it just shows reset of the WAN interface due to apinger not able to ping its gateway, but nothing indicacting why there is this slow down / unresponsiveness issue.

As I couldn't copy the logs out of the machine I simply did a "cp -rf /var/log /var/log.$date" as I wanted to preserve them. After that I simply rebooted the VM and everything started working again., as if there was no issue in the beginning.

Yes, its an old ESX, the underlying hardware is reasonably old, but I just don't have any explanation on why this happens, and months apart, in two different kernel major versions and why the issue stopped immediately after the reboot.

Has anybody seen this? Any thoughts? I might migrate this gateway to a bare metal for a few weeks just to have the ESX out of the equation but I don't even know if I can justify that. I googled a bit "vmware unresponive" + "opnsense/pfsense/freebsd" and no joy

Thx