Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - mcdeltat

#1
This can be marked as solved. I was of course following the docs for the new Instance Based "Road Warrior" setup, which can be found here: https://docs.opnsense.org/manual/how-tos/sslvpn_instance_roadwarrior.html

In there, the tiniest comment "Leaf Certificate - Type Server: Set the Common Name to the FQDN of this machine." bears all the weight here. You must set a CN value, no matter what it is, for things to work. I don't use a FQDN on my router yet, so I had omitted it. I put one that is a subdomain of my actual domain, but is not an actual DNS entry anywhere on my network. The other "Self-Signed Certificate Chains" doc also points to this, saying to put "leaf-certificate.example.com". See: https://docs.opnsense.org/manual/how-tos/self-signed-chain.html

Once I had reissued the certificate the OpenVPN instance was using, I restarted the instance from the Dashboard. I exported the ovpn client file again and imported.


RANT: Can we please get better warnings in OpnSense??!! I've been using it for 7+ years now and every single problem I have pulled my hair on can be chalked down to "UI does not clearly tell you what is a required field or warn you of obvious issues."

If modern OpenVPN/openssl implementations demand a CN, then it should either:
1) Be a required field when creating a new leaf certificate.
2) Flagged as a health status issue up top that says "Your OpenVPN instance certificate chain is missing a Common Name."

I'm tired boss. This took 5+ hours out of a good weekend. A tiny sentence, not in bold, not italicized, with no warnings from the router itself. That took 5 hours.
#2
I was working on adding new Linux devices to my existing OpenVPN instance and no matter what I do, I get this error (note, PII swapped with <Value> brackets, but they are correct values). It seems that opnSense is generating incorrect ovpn files that miss the CN portion of the Subject.

2026-09-06T03:42:25.164197-07:00 user-precision nm-openvpn[14463]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2026-09-06T03:42:25.164761-07:00 user-precision nm-openvpn[14463]: TCP/UDP: Preserving recently used remote address: [AF_INET]<public_ipv4>:1194
2026-09-06T03:42:25.164985-07:00 user-precision nm-openvpn[14463]: UDPv4 link local: (not bound)
2026-09-06T03:42:25.165140-07:00 user-precision nm-openvpn[14463]: UDPv4 link remote: [AF_INET]<public_ipv4>:1194
2026-09-06T03:42:25.180286-07:00 user-precision nm-openvpn[14463]: VERIFY ERROR: could not extract CN from X509 subject string ('C=<Country>, ST=<State>, L=<City>, O=Personal, emailAddress=<email@email.com>') -- note that the field length is limited to 64 characters
2026-09-06T03:42:25.180367-07:00 user-precision nm-openvpn[14463]: OpenSSL: error:0A000086:SSL routines::certificate verify failed:
2026-09-06T03:42:25.180394-07:00 user-precision nm-openvpn[14463]: TLS_ERROR: BIO read tls_read_plaintext error
2026-09-06T03:42:25.180424-07:00 user-precision nm-openvpn[14463]: TLS Error: TLS object -> incoming plaintext read error
2026-09-06T03:42:25.180450-07:00 user-precision nm-openvpn[14463]: TLS Error: TLS handshake failed
2026-09-06T03:42:25.180476-07:00 user-precision nm-openvpn[14463]: SIGUSR1[soft,tls-error] received, process restarting

Strangely enough, when using the official OpenVPN App on an iOS device everything works as expected. I export the client certificate, I open the ovpn file, I change no values, I connect. This bug seems specific to my Linux devices.

Current Server Stats:
OPNsense 26.7.3_11-amd64
FreeBSD 15.1-RELEASE-p3
OpenSSL 3.5.8

Current Client Stats:
Linux Mint 22.3
openssl/noble-updates,noble-security,now 3.0.13-0ubuntu3.15 amd64

Notably, the file that comes from opnSense Client Export has this at the top, missing the CN.
verify-x509-name "C=<Country>, ST=<State>, L=<City>, O=Personal, emailAddress=<email@email.com>" subject

I tried manually modifying the file prior to import to include the CN, which did not work. I also tried disabling TLS Validation:
verify-x509-name "C=<Country>, ST=<State>, L=<City>, O=Personal, emailAddress=<email@email.com>, CN=<username>"

Looking at the contents of the <cert> section of the ovpn file, we get this from "openssl x509 -in ~/Downloads/user-laptop-x509.txt -noout -text":
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 11 (0xb)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = <Country>, ST = <State>, L = <City>, O = Personal, emailAddress = <email@email.com>, CN = intermediate-ca
        Validity
            Not Before: Mar  2 08:24:50 2026 GMT
            Not After : Apr  3 08:24:50 2027 GMT
        Subject: C = <Country>, ST = <State>, L = <City>, O = Personal, emailAddress = <email@email.com>, CN = <username>
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    <MODULUS>
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
            Netscape Comment:
                OPNsense Generated Client Certificate
            X509v3 Subject Key Identifier:
                <X509v3 Subject Key Identifier>
            X509v3 Authority Key Identifier:
                keyid:<X509v3 Authority Key Identifier>
                DirName:/C=<Country>/ST=<State>/L=<City>/O=Personal/emailAddress=<email@email.com>/CN=intermediate-ca
                serial:00
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:

Anyone got any idea what's going on here?
#3
Posting to put another name behind the request.

I run OpnSense for personal use at home to learn networking. I've been running it for about 3 years now. The lack of notifications has bitten me in the butt multiple times, every single year. I've been meaning to request it, literally every single year.

I just spent 5+ hours troubleshooting my OpenVPN setup. I knew the client (user) certificate was expired so I generated a new one. I was reading logs, troubleshooting my DDNS, all kinds of things. Then I decided just to nuke and go again. Then I realized my CA only has a 2-year expiration, so generating new client certificates was never going to work. This already happened to me twice because the default for CAs is 1 year, if I'm not mistaken. So I caught it in the first year, and now in year three. I'll be setting up notifications, monitoring, or something with Ansible.

There are so many ways the user story can be made better here. For example:
1. Use CSS to color expired certificates or CAs to draw the user to that section.
2. When generating client certificates using a self-signed CA, throw an error when the CA is expired.
3. Improve logging to say that it's expired and not just generic "TLS Peer Certificate Validation Failed" or things like that.

These would at least cut down on my 5 hour troubleshooting session and make this less painful when people do forget.
#4
General Discussion / Re: PXE Boot Raspberry Pi
April 27, 2022, 05:30:49 AM
Quote from: cookiemonster on April 26, 2022, 11:04:20 PM
I had to overcome this when I setup my tutorial, albeit it is not for uefi. I had to packet capture to figure it out, hopefully you won't have to and can use my note at the bottom of the tutorial.
https://forum.opnsense.org/index.php?topic=25003.0

Thanks for that. Your tutorial is one of the many tabs I had open to troubleshoot this ha. I concluded the same thing as you.
1) It seems that the RPi may not be cable of UEFI.
2) It is expecting very specific file names.

I think my next step is to try with their Raspberry Pi OS (Debian) and see if that works. Then I might go back to Ubuntu. It's for a Kubernetes cluster, so I find it very important to be able to blow these up and reinstall whenever I mess things up with my Ansible code.
#5
General Discussion / PXE Boot Raspberry Pi
April 25, 2022, 06:42:09 AM
I've been working through PXE booting a Raspberry Pi 4 on my network for quite a few hours now and not sure what I'm missing. Hoping to make a video tutorial at the end of all this to avoid the forums getting hit with this constantly.

Boring Details:
OPNsense 22.1.6-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1n 15 Mar 2022
Intel® Core™ i5-7200U CPU @ 2.50GHz (2 cores, 4 threads) (Qotom Box)

I'm mostly following this official guide from Ubuntu https://ubuntu.com/server/docs/install/netboot-arm64

I've installed the os-tftpd package on opnSense. I downloaded the latest live server image (Jammy 22.04) from here: https://cdimage.ubuntu.com/releases/22.04/release/ubuntu-22.04-live-server-arm64.iso

From there I copied over the following files to my tftp server in /usr/local/tftp:
1. casper/initrd
2. casper/vmlinuz
3. grub/grub.cfg
4. grubnetaa64.efi.signed

The contents of my grub/grub.cfg file are:
set timeout=30

loadfont unicode

set menu_color_normal=white/black
set menu_color_highlight=black/light-gray

menuentry "Install Ubuntu Server (Jammy 22.04) (Pull ISO from Web)" {
        set gfxpayload=keep
        linux /casper/vmlinuz url=https://cdimage.ubuntu.com/releases/22.04/release/ubuntu-22.04-live-server-arm64.iso only-ubiquity ip=dhcp ---
        initrd  /casper/initrd
}

menuentry "Try or Install Ubuntu Server" {
        set gfxpayload=keep
        linux   /casper/vmlinuz quiet ---
        initrd  /casper/initrd
}
menuentry 'Boot from next volume' {
        exit 1
}
menuentry 'UEFI Firmware Settings' {
        fwsetup
}


To test things out, I went to another machine that is on the same LAN as the target machine. I ran 'tftp 192.168.x.x' and then 'get grub/grub.cfg' to which I get 'Received 608 bytes in 0.0 seconds'. Trying the same get command on a file that doesn't exist yields "Error code 1: File not found". Perfect.

So then I jumped into the GUI and made what I expect to be the final changes, but then nothing happens. Under Services -> DHCPv4 -> LAN I have the following settings:
1. TFTP server -> Set TFTP hostname: 192.168.x.x (same as the one tested above)
2. TFTP Server -> Set Bootfile: /usr/local/tftp/grub/grub.cfg
3. Network Booting -> Enable Network Booting: Checked
4. Network Booting -> Set ARM UEFI (64-bit) filename: grub/grub.cfg
5. Network Booting -> Set root-path string: /usr/local/tftp/grub/grub.cfg


The RPi then proceeds to just cycle through the boot process. Tries the SD card, gets an IP from DHCP, gets the correct TFTP Server IP, but then states "TFTP 1: File not found."

So what am I missing? Is it because the RPi can't boot UEFI? Unsure of where to go from here since my machine on the LAN finds it just fine.