Messages

are you a bot?

I just spent a lot of time trying to figure out why my user's certs would not show up in the client export in OpenVPN. I verified the certificate was correct and everything was matching, and the OPNsense GUI recognized it as a certificate associated with the user just fine, but it still would not show up in the client export. I reverted to creating the OPNsense config files manually. I had another OPNsense box I'm using, and I did another cert sign request from there, then imported it into my other box, and the client export showed up just fine. While on the other box where I did the cert sign request it did not show up in client export.

The issue was that when you generate a certificate using the certificate sign request, it will not show up in the client export. However, if you do an import of that same certificate, it will then show up in the client export. So there's some bug with client export and certificate sign requests vs. import certificate.

UPDATE: Yup, I just deleted the certificate sign request cert entry then reimported the same cert under the import certificate dropdown and the cert then appeared inside the client export when it wasn't before.

EDIT: I've updated my post a few times to try and make my problem clearer. My goal is to periodically fetch the CRL from my Issuing CA so OpenVPN can enforce client cert revocation. Auto-fetch is enabled but the CRL Name column is empty for both CAs nothing has been fetched. The buttons in the Revocation doesn't do anything when clicked. The CRL URL is reachable from the OPNsense shell over HTTP.

Here is my current certificate configuration. I have an offline Root CA → online Issuing CA. Both CA certs imported into System → Trust → Authorities. I confirmed that the Issuing CA's CRL is reachable inside OPNsense shell, fetch succeeds, returns valid 1KB DER. "Auto fetch CRL's" is enabled in System → Trust → Settings. "Store intermediate" and "Store CRL's" also enabled.

Why auto-fetch doesn't help me:

The Settings tooltip says auto-fetch downloads CRLs from CDPs in CAs in the trust store. For my hierarchy my Root CA cert has an empty CDP, and the Issuing CA cert's CDP points to the Root's CRL. The Issuing CA's CRL URL only appears in CDPs of leaf certs, which aren't in the trust store. So auto-fetch can never discover the URL for the CRL.

What I've tried in System → Trust → Revocation

Clicking the + on the Issuing CA row opens a dialog with a Method dropdown showing only, "Internal: build CRL from OPNsense issued certs", "Import existing" which seems to only accept PEM.

Is there a supported way in OPNsense to configure periodic URL-based CRL fetching for an externally managed CA whose CRL URL is not advertised by any imported CA cert?

Thank you, that was my thinking as well. I'll give this a try.

Hello, is creating the openVPN interface not required? I realized it was working without me taking that additional step. I went ahead and created the interface enabled it and everything seems to be fine even without any rules. Wouldn't this hit the default block rule?

The guest access...

I need to provide VPN access to some remote users and was wondering the best way to do that. I had originally thought maybe I should setup a separate openVPN instance for my guests, and then just add some custom rules for that specific interface. However, i see that there is also CSO.

I'm doing this temporarily prior to setting up netbird. What is recommended for my situation? I will be authenticating this user against LDAPS which has already been setup and working for my admin group.  This user however would authenticate against a different group than the admin group which would not provide access to the firewall but the group would have permission to connect to this specific CSO or OpenVPN instance. What's the best way to handle that?

The guest would be restricted to a single VM / git server / active directory authenticaton / local splt-dns.  😁

Lol, I was wondering that. However, it does seem that the other stuff I did fixed it? My connection is more stable with those other changes I made. The traffic graph also looks like what I'm used to seeing in the OpenVPN Connect UI.

I went ahead and enabled those options but i get an error message. You can see below. It doesn't look like this is supported. Also, I see that there are these same options in the instance itself: Fragment Size, TUN device MTU, and also MSS Fix.



Should this be set in the instance as well ?



I also noticed that the interface was never assigned although it was still green in the GUI. I did go ahead and enable it. The interface has its own MTU and MSS options. Is there anything that needs to happen here?

What I ended up doing is setting TUN device MTU: 1400 and checking the MSS fix within the instance options. I then added only "mssfix" and"tun-mtu 1400" to my client export config.

Thank you! I will try this and get back to you if it works.

Hello, I see when I create a filter at the top I can only use the AND is it possible to use OR to filter the live logs?

Hello, my openVPN client keeps randomly disconnecting for now reason and i see `IP packet with unknown IP version=0 seen`. I selected MSS fix option within the instance config, but it still seems to happen. I am using the following certification I'm not sure if this is increasing my packet and I need to specify a different MTU.


TLS static key

Public Key Algorithm: Elliptic Curve Cryptography (ECC)

Key Size: 521-bit

Elliptic Curve: NIST P-521 (secp521r1)

Signature Algorithm: ECDSA (Elliptic Curve Digital Signature Algorithm) with SHA-512

Hello, I was able to get the os-git-backup backup working on my self-hosted Gitea server. However, I realize now that using this tool causes you to commit all the private keys in your config.xml to the repo. This is a privately hosted Gitea server, so the security concern is somewhat mitigated, but I still don't like the idea of having keys out there that I will easily forget about. I think a warning about this happening might be worth including. I didn't consider it while I was setting it up.

Is there any way to mitigate this risk while using this tool?

Considering that the configuration file is highly structured and consistent would it be feasible to implement an option that parses and redacts/removes sensitive XML tags prior to the commit?

There is a way to clean files using .gitattributes however I don't have experience using it.

https://git-scm.com/book/ms/v2/Customizing-Git-Git-Attributes#filters_b