Linuxmuster-setup läuft nicht durch (SSH-Verbindung zur Firewall)

Hello,

My current test system is Proxmox 8.4.1, Opnsense 25.1.7, Ubuntu 22.04.5, lmn 7.2-81 all updated to the latest, and I followed the documentation except for the default ip address (I used 172.16.x.x/16 instead of 10.x.x.x/16, and I used 11 instead of 254 for the gateway, but I tried that with 254 too and it didn’t matter) and hostname (trefortserver) and domain name (eltetrefort.lan).

yes … that’s the same when you use the ACME Client on the OPNSense. The LE-Certs are being renewed automatically:


Of course it’s also possible to use a wildcard-cert for your *.domain.

But of course this won’t fix the problem with the lmn-appliance script … so let’s see if Thomas can find the problem?

This acme-client plugin is not part of the default opnsense install, could this be a problem? Would the lmn script use it? If so you could try to run the script after installing this only. If not then if I install it afterwards could I use it to create certs for the server?

you are right. I use it on the OPNSense for years now without problems :man_shrugging: . (When I installed the v7-server back in 2019 I’ve chosen to take our FQDN internally. That’s why I needed a „real“ cert there, too. I still don’t know exactly if it was a good decision)

I don’t know if any oft the setup scripts will accept a cert that you copied on the server.

btw: sorry – I didn’t know that it was the wrong place for your issue on github but you can simply re-open it in linuxmuster-base7.

The setup script doesn’t care about what you do afterwards with the certificates.

that’s ok … but as I see it @Fenyo wants to copy the cert on the v7-Server first and then use the setup-scripts??? (It’s just a workaround because the default server.cert.pem and the cert-bundle are missing after his default installation …)
Right :thinking: :interrobang:

Ok, I have reopened it in the other github repository, at the moment it would be good for me if the ssl cert keypairs are not created properly during installation, if we could find some afterwards solution, either manually under command line or with one of the opsense automated solutions, which I can copy to server afterwards. Question if this bug affected other things during the installation.

Also, I found these logs that were created during websetup, the whole thing is based on the fact that the firewall doesn’t create ssl authentication properly anymore, so there are problems with import subents (and dns resolve doesn’t work until after creating the server.cert.pem file) and creating the keytab.
Maybe this could be the starting point?

which version for the OPNSense did you use for your initial setup?

From the docs:

Hinweis
Die zuletzt freigegeben OPNsense Version für das Setup von linuxmuster.net v7.2 ist die Version 24.1 [Stand: Februar 24].

wget https://mirror.informatik.hs-fulda.de/opnsense/releases/24.1/OPNsense-24.1-dvd-amd64.iso.bz2

The latest one (25.1.7), but I asked in #40 if I should try with an earlier one, but you said that it works with the latest one, and the documentation itself says to update opnsense before the lmn setup.

Was just another idea … there was a bug some time ago. Maybe you can try the initial setup with this version again and upgrade to the latest version later. But no guarantee … :man_shrugging:t2::thinking:
(#40 was answered by Arnaud btw)

But the problem still seems to be on the v7 Server and not on the OPNSense

By you I meant plural, not necessarily you specifically, but in Hungarian the plural is conjugated in a completely different way than in Indo-European languages, so if someone makes such a mistake in a sentence they are almost certainly Hungarian, the other such gender, which also doesn’t exist in Hungarian, so even with such a conjugation error you can be almost sure you are dealing with a Hungarian.
I’ll try with opnsesne version 24, but it shoots back to start field almost completely, so that’s time consuming, so I’ll do that tomorrow maybe.

ok … intersting :slight_smile:

You should use the snapshot features of proxmox. :sunglasses:
Best practice: Do the initial setup of the OS → make a snapshot → run the setup-script → see if it works → if not → return to the last snapshot and so on … works like a charm.

With ZFS in the background it’s even cooler as you can revert to any state within seconds.

Yes, I like the quick and easy snapshot management in Proxmox, but for opnsense I only have the pre-setup lmn of the already installed and updated version 25.1.7, and for the lmn itself the moment before the lmn-appliance script is run, that might do, but for Opnsense I think I have no choice but to start over if I want to try an older version.
Say, I don’t know which version of opnsense @thomas used for his test system.

v25 should work, too …

And: linuxmuster-base7/Renew_certs.md at master · linuxmuster/linuxmuster-base7 · GitHub

Then there’s not much point in testing with 24, I tried the renew-cert script too, but nothing happens if I just choose to renew the server certs, if I choose all, it creates new ones for the firewall (which still don’t work in https mode, just crossed out), but the server only gets a 0 byte file and some other unfinished too.

… and does this work?
linuxmuster-renew-certs --dry-run

I haven’t tried this yet, I’ll check it out tomorrow.

So the chain of events we have so far found out from the log files;

  1. during websetup the firewall ssl authentication seems to be created but doesn’t actually work (crossed out https)

  2. therefore the server.cert.pem file is not created and the cert.bundle only contains half of the key pair

  3. therefore the name resolution doesn’t work (this was the first clue, samba doesn’t work after the websetup restart, its log file showed (server. cert.pem file was missing, then it was found out that the bundle file must be corrupted, the server.cert.pem file could be created manually, after that the name resolution and samba worked, but webui still did not work because of the corrupted bundle file, this was found out from the ajenti crash log))

  4. so during the websetup, the steps that require name resultion fails: subnets improt, kerberos keytab generation.

acutally the lmn server can be set up without the firewall. in the lmn-prepare script is an option not configure the firewall. so i dont think your logic is right, that the cause of all the problems is the firewall certs :slight_smile:
i installed the lmn server 7.2 in march with opnsense 25.1 with a local fqdn musterschule.linuxmuster.lan. i had to change manually one of the script files so it ran through with opnsense 25.1 and not 24.1…
after the setup, there were the dns problems in the config with opnsense. but u have already fixed all of this…
I didnt user the websetup, but the terminal setup. back then the problem was that an emtpy file cacert.pem (I think) had to be created before the setup. but this has been fixed i think. not sure. now since u have snapshots… u can now easier check where the problem is in the end…

Well, yes, I know that you could install without a firewall, but we want a firewall and a proxy, and I think these are required for the exam mode, which we would also use
The reason for the faulty firewall certs, apart from the fact that https is just crossed out for the firewall, I think is based on the logs of the webesetup (yes I tried it with terminal setups too, but that didn’t matter either), where it seems that you can’t connect to the firewall on port 443, that’s why things are stuck. This is setup-final.log

And this is the importsubnets crash and firewallceratekeytabcrash from websetup time;

And --dry-run for renew-cert is just testing, so nothing happens, for real renew request, it’s just looking for the wrong name of the server cert files.