netstat -ssp ip
ip:
178284 total packets received
150415 packets for this host
12639 packets forwarded
13480 packets not forwardable
166008 packets sent from this host
13248 output packets discarded due to no route

netstat -im
780113/8752/788865 mbufs in use (current/cache/total)
2850/7748/10598/1000000 mbuf clusters in use (current/cache/total/max)
33/7557 mbuf+clusters out of packet secondary zone in use (current/cache)
8198/3381/11579/524288 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/524288 9k jumbo clusters in use (current/cache/total/max)
0/0/0/124480 16k jumbo clusters in use (current/cache/total/max)
233528K/31208K/264736K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0 sendfile syscalls
0 sendfile syscalls completed without I/O request
0 requests for I/O initiated by sendfile
0 pages read by sendfile as part of a request
0 pages were valid at time of a sendfile request
0 pages were valid and substituted to bogus page
0 pages were requested for read ahead by applications
0 pages were read ahead by sendfile
0 times sendfile encountered an already busy page
0 requests for sfbufs denied
0 requests for sfbufs delayed

Ok will do. Which logs specifically, and where are they located? Any other relevant info needed? Thanks for the help.

I've been seeing this as well. It shouldn't be pointed at a log file directly since we call it from syslogd. Something must have changed in its config recently to trigger the error. I opened https://redmine.pfsense.org/issues/9971 to look into it.

Thanks!

@kiokoman said in Feedback request: Recent OpenVPN Changes:

i didn't even know about this ..

Then I did something right :-)

Now wait until you hear about the massive IPsec changes I made last week that (hopefully) were also imperceptible to most people...

@JeGr said in Feedback request: Recent OpenVPN Changes:

would that make it possible to read CRLs from a remote system so it only has to be managed at one location without "syncing"

No, it's only about how OpenVPN reads/processes them locally, using capath to setup a CA+CRL structure directory, rather than using separate ca and crl-verify directives.

Hi all! Finally I could find a solution to this problem. I do not recommend using it in production at all and surely there is a better way to fix this.
1- Download attached files.
2 - Download WinSCP and connect to pfSense by ssh.
3 - Copy libcrypto.so.8 to /usr/lib
4 - Copy libssl.so.8 to /usr/lib
5 - Copy ssl_crtd to /usr/local/libexec/squid/
5 - Copy squid.inc in /usr/local/pkg
5 - Reboot pfSense

For those interested, the error was due to a change in squid 4 in the ssl_crtd executable that was replaced by security_file_certgen, which is the file I am sharing with the name changed to ssl_crtd, this should really be solved by modifying in depth squid.inc. libcrypto.so.8 and libssl.so.8 are libraries needed to run security_file_certgen. If someone wants to read more I leave a couple of links.

https://www.systutorials.com/docs/linux/man/8-ssl_crtd/
https://www.mankier.com/8/security_file_certgen

FILES: https://1drv.ms/u/s!AmdqTK4gIf5X7QJ3FZMXer-Rm-CV?e=VccoI5

NOTE: I got the libcrypto.so.8 and lib.ssl.so.8 files from pfsense 2.4, squid.inc was modified by me (line 1143)
tested in 0.4.44_9.

greetings to all from Argentina.

Jorge Alejandro Cazón.

@w0w Thanks. It's running as a proxmox instance so I reverted back to an earlier snapshot. Memory / disk are OK. Might have been a glitch in the matrix.

https://redmine.pfsense.org/issues/9936

Of course it's slow, the ENV command disables AES-NI. Did you read what @viragomann or @jimp wrote?

@viragomann said in openvpn no option for AES-NI:

Run openssl speed without stating an engine.
openssl speed -elapsed -evp aes-128-gcm

than run it again with AES-NI turned off:
OPENSSL_ia32cap="-0x200000200000000" openssl speed -elapsed -evp aes-128-gcm

So of course your test with the ENV in front is slow:

@yon-0 said in openvpn no option for AES-NI:

env OPENSSL_ia32cap="-0x200000200000000" openssl speed -elapsed -evp aes-128-gcm

...
aes-128-gcm 65904.02k 77740.47k 81972.82k 83137.82k 83638.57k 83525.96k

compared to the one before without the ENV trigger:

openssl speed -elapsed -evp aes-128-gcm
...
aes-128-gcm 223257.45k 683793.45k 1276418.05k 1592591.84k 1677789.34k 1686279.07k

FYI- After trying a few tools and finding that the common ones I'm used to (sslscan and nmap --script ssl-enum-ciphers) do not support TLS v1.3, I happened across one that does and has a nice set of tests: testssl.sh

Among its other (very verbose) output:

Testing server preferences Has server cipher order? yes (OK) Negotiated protocol TLSv1.3 Negotiated cipher TLS_AES_256_GCM_SHA384, 253 bit ECDH (X25519) Cipher order TLSv1.2: ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA DHE-RSA-AES256-CCM8 DHE-RSA-AES256-CCM DHE-RSA-AES256-SHA256 DHE-RSA-AES256-SHA TLSv1.3: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256

@johnpoz @jimp Im on stable 2.4 so for me that HAproxy on develop 2.5 is so fresh is really good news, thanks for them. I will test this at VM ☺. So did you know eta 2.5 will become stable?

Right, issues that affect security but all issues that affect security no matter how minor they are deemed

That's a filesystem crash, you need to run fsck or reinstall. Possible that the other panics caused it (or made it worse).

Thanks Jim!

No rush, I'll just wait for the next build to come out.

@kiokoman good.

Change all four instances

Yeah, not a big problem - just that as i remember, the behaviour was different when I tried with 2.4.4. That's why it had me stumped for a while. On the other hand, I've been testing a lot of things and changing versions / settings so I might be wrong..

All right, I'm now sure of when the crashes are provoked, I just have no idea what is causing them.

I have the following version installed:

2.5.0-DEVELOPMENT (amd64) built on Mon Oct 14 00:22:51 EDT 2019 FreeBSD 12.0-RELEASE-p10

Furthermore, I have the FRR package installed, verion 0.6.3_1. Each of the four test firewalls is configured to connect via IPSec to two other units, in a "circle" configuration. On top of IPSec, they are configured with Phase 2 VTI and OSPF Routing.

The important setting is "IPv6 Configuration Type" for the WAN interface. It this is set to DHCP6, as it was by default, the firewalls crash regularly. If it is set to "None", there are no crashes (or at least they are so infrequent that I haven't seen them yet). Also, as described above, DHCP6 causes a lot of log entries and blocks updates.

Crash log attached:
fw3_20191014.zip

It's not impossible that the IPv6 config on the upstream pfSense box dealing as the WAN gateway and DHCP server is not ideal - but in any case, a misconfiguration here shouldn't cause crashes IMHO.

I can share config backups if needed, since this is a test system. I'm also fine with doing any more tests, but I don't know what.