Messages

I just want to update this thread.

I opened a case with Deciso support. They validated that my configuration was correct. Next, they set up test machines on their side. What they found was that OpenVPN Peer to Peer (SSL/TLS) is indeed broken. They were able to get Peer to Peer (Shared Key) to work and that is the configuration I ended up going with, at least until TLS is fixed.

In summary, don't use Site to Site (SSL/TLS). Use Site to Site (Shared Key) until this issue is resolved.

Forgive my newbieness but it appears to me that Suricata while being multithreaded is only using one core on my OPNSense box. I noticed this while doing multiple downloads of large files simultaneously.

I initially noticed it because I wanted to check the load on my new OPNSense firewall. After running 'top' from the shell I noticed one CPU running Suricata was pinned at 100% while the other was relatively idle. I then did some checking about Suricata to see if it was multithreaded or multiprocess. It claims to be multithreaded. I tried the downloads again, same behavior so I put 'top' into threads mode. Sure enough, multiple threads but the ones under load were running on the same core.

I don't believe this is the correct or expected behavior for a multithreaded application.

System in question is OPNSense 17.1.2 running on a x86_64 Core 2 Duo with 2GB ram and SSD drive.

Steps to reproduce:

1) Download multiple streams of "stuff" at a sufficiently high download speed

2) run top or something else to watch the load on the system. Press "H" to view all the threads under load running on one core (there were other Suricata threads but with little to no CPU time)

Can anyone else confirm this behavior?

LibreSSL version installed and working. I'll post again tomorrow to confirm.

I've been running it all week on my home box. Nothing weird in the log files. No angry wife or children. Looking fine to me.

AAaaahhhhh my kids can't stream Netflix!

Just kidding. Seems fine so far  :)

Ean,

I missed the "16.7" does the same thing, sorry! In this case, it should only be a configuration glitch.

Which routing direction isn't working exactly?


Cheers,
Franco

I've been unable to figure that out. I'm attaching the server and client XML configs with extraneous and private info removed. Might just be a wrong setting that is easy for a second set of eyes to spot?

Well, unfortunately, I've updated the kernel and no luck. Then I tried the sysctl tuning and still no luck. I must be doing something stupid here.

The fix will be part of 17.1.1. Packages are unlocked prior to the major upgrade of all packages as they should.

This may have consequences for manually installed packages, but we need to make sure we provide a correct platform where it can actually be installed again.


Cheers,
Franco

I would humbly say that manually installed packages are outside the scope of the OPNSense team's responsibility anyway. If you're savvy enough to install unsupported packages, you get to maintain them and keep both pieces if it breaks ;-) Just my 2 cents.

Thanks again for the help!

Thank you Franco! I'll just wait until tomorrow for the 17.1.1 update. And I will stop beating my head against it and be happy that I'm not losing my mind  :)

Btw - I absolutely love OPNSense. I've been hacking on OpenBSD firewalls for years and this is just so much nicer, easier and with batteries included.

Also - someone over there was supposed to email me a support contract but I never received it. Is there someone I can reach out to?

Thanks again!
Ean

Hi folks,

I've been trying to set up a site to site tunnel with OpenVPN on both 16.7 and 17.1 to no avail. I have the actual tunnel connecting just fine. I have an additional OpenVPN server service running on the same OPNSense system for remote clients and that is working also. The site to site tunnel is pingable from the OPNSense firewalls. The firewalls themselves can ping remote hosts on the respective networks.

Here is the setup -

Home (client) network: 192.168.64.0/24
Work (server) networks: 192.168.29.0/24;172.16.29.0/24
OpenVPN network: 10.0.100.0/24

It seems like a routing problem however when I check the routes on both OPNSense boxes they look right

Home (client)
ejprice@hades:~ % netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            148.74.168.1       UGS        bge1
10.0.10.0/24       10.0.100.1         UGS      ovpnc1
10.0.100.0/24      10.0.100.1         UGS      ovpnc1
10.0.100.1         link#10            UH       ovpnc1
10.0.100.2         link#10            UHS         lo0
127.0.0.1          link#7             UH          lo0
148.74.168.0/21    link#2             U          bge1
148.74.175.197     link#2             UHS         lo0
167.206.13.180     00:0a:f7:13:24:25  UHS        bge1
167.206.13.181     00:0a:f7:13:24:25  UHS        bge1
172.16.29.0/24     10.0.100.1         UGS      ovpnc1
192.168.29.0/24    10.0.100.1         UGS      ovpnc1
192.168.64.0/24    link#1             U          bge0
192.168.64.1       link#1             UHS         lo0

Work (server)
ejprice@ppt-fw:~ % netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            24.187.203.129     UGS        igb0
10.0.10.0/24       10.0.10.2          UGS      ovpns1
10.0.10.1          link#9             UHS         lo0
10.0.10.2          link#9             UH       ovpns1
10.0.100.0/24      10.0.100.2         UGS      ovpns2
10.0.100.1         link#10            UHS         lo0
10.0.100.2         link#10            UH       ovpns2
24.187.203.128/29  link#1             U          igb0
24.187.203.130     link#1             UHS         lo0
24.187.203.131     link#1             UHS         lo0
24.187.203.133     link#1             UHS         lo0
127.0.0.1          link#6             UH          lo0
172.16.29.0/24     link#12            U      igb1_vla
172.16.29.254      link#12            UHS         lo0
192.168.29.0/24    link#2             U          igb1
192.168.29.251     link#2             UHS         lo0
192.168.64.0/24    10.0.100.2         UGS      ovpns2
192.168.100.0/24   link#4             U          igb3
192.168.100.1      link#4             UHS         lo0

I have tried both network topology settings. Currently, the server is set to topology subnet but I tried net30. I have no preference here, I just want it to work  :)

Any help would be appreciated. I've been beating my head against this for a week now.

Cheers!
Ean

Unfortunately, no. It's working fine for me.

Sounds like you might have a mismatch where one of the certificates was created by a different CA. Is that possible? Can you look at the entire certificate chain and verify that the same CA was used? And the same CA is selected in your server config. The devil is in the details with certificates.

Under System/Trust/Certificates click the "i" icon and take a look at the issuer right up at the top. Make sure the common name (cn) matches that of your CA in System/Trust/Authorities.

Hope that helps!

Disregard. I found the work-around in issue #1368.

Hi folks,

I'm setting up a brand new 17.1 server. I have configured LDAP and the users are testable in /diag_authentication.php

However, the import user icon is not showing up on the /system_usermanager.php.

So I went directly to the /system_usermanager_import_ldap.php which tells me "Could not connect to the LDAP server. Please check your LDAP configuration."

The OPNSense server is bound to the LDAP server and I see the queries returning data when I use the /diag_authentication.php so it seems unlikely to me that there is a connection issue. I used the same setup in 16.7 with no issues.

Lastly, I have added the patch for the CSRF errors because I couldn't add the LDAP server without the patch. I don't know if this is somehow related but I figured I should mention it.

Thanks in advance!
Ean

That was my thought exactly. Originally it was a learning opportunity and a challenge. Now is is just a pain 😡

Thank you for all the help! I've learned some good stuff about OPNSense and FreeBSD.

No problem at all! I really appreciate the help.

I think it's really dead 😢. Name resolution does not work at all from the shell. I confirmed the Google DNS server is in /etc/resolv.conf. I confirmed the system can traceroute to the Google NS. So just for fun and because I had nothing to lose, I edited the /usr/local/etc/pkg/repos/origin.conf file and hardcoded the IP address of the OPNSense repository.

I received a connection timeout upon trying pkg bootstrap even though we're bypassing DNS. Traceroute completes successfully. Telneting the pkg repo on port 80 does not complete. I've disabled Squid and paused the port 80 redirect. I've also tried https which should bypass squid and the pf rules since SSL bump wasn't configured. I'd say this is indicative of a much larger problem.

Thoughts?