Messages

Ah thank you, that makes sense.
We always update the masters first because it's better for us.

As you correctly guessed right, the HA sync is executed automatically after a certain time.
Then I will simply adapt the script if there are HA sync compatibility problems between versions.

We have many HA setups running here.
Updates are distributed automatically as long as there are no errors in the previous FWs.

We've never had this problem before.

I've now also taken a closer look at one, the config looks the same so far.
Logging in was only possible by resetting the root pw in single user mode. But also here, the login was only possible via serial, the gui login did not work.

Why SSH login was no longer possible, well ... the .ssh folder was empty. It must have been deleted by the update for whatever reason.

Maybe it was just bad luck, let's see ...

Hi,


are you aware of any problems with high availability setups after updating to 25.1 (from 24.7.12_2)?

We have two setups that no longer work after the master firewall was updated to 25.1. The backup firewalls are still on 24.7.12_2.

The issue is that logging into either backup firewall is no longer possible after updating the master to 25.1. The backup WebGUI login page is still accessible, and ping works. It also appears that the backup firewall itself remains correctly configured.

Both password and SSH authentication (keys) are rejected.
System → High Availability → Status displays:
"The backup firewall is not accessible (check user credentials)."

However, this only affects the backup firewall, the master runs without issues in both setups.
So far, we have updated four HA setups to 25.1, two encountered this problem, while two did not.


Regards,
R1mSG

The import browser was merely a tool to list DN/CN.. All you need to do to "import" is match the CN on the LDAP as a user name? That's all there is to LDAP imports. The magic happens in the authenticator, not the user.


Cheers,
Franco

Ah, the "match the CN on the LDAP" was a point that wasn't entirely clear to me.
After the update, there is no longer a visible difference between local and AD-imported users.

I was able to test it successfully now, thanks :)

I'm also a bit confused how this is supposed to work.

Previously, it was straightforward (in my opinion) you could simply import the user(s) and then link an OTP to each one.

Now, when I migrate, what happens?
Are the users and all associated OTPs:
    Deleted?
    Converted to "local DB"?


Additionally, how can I automatically import users?
I wasn't able to get this working using the "Automatic user creation" function.

Hey,

sorry for the late feedback.

It seems to work again in the meantime.
I tested it with several firewalls and it worked with all of them without any problems.
Why it didn't work with all of them bevor, I can't say.

About the "<openvpn-csc>" entries.
Yes, they are no longer included in the config.xml files.
But I rather assume that these were replaced in the last updates by "<Overwrite uuid" entries.
At least in old backups I can find the "<openvpn-csc>" entries in any case.
But I have not deep dived into the whole thing.

Greetings,
R1mSG

Hey,


after the Client Specific overrides were changed in the last updates, I noticed that they are not synchronized via High Availability Synchronize at all.

The options under System: High Availability: Settings are all set.
Is this the way it should be?
I could not find anything about this anywhere.


Greetings,
R1mSG

btw, solution was.

The default mode of "opnsense-update" was changed to "opnsense-update -bkp" last year.

See also:
https://github.com/opnsense/core/issues/6128

Hi,

i have two questions regarding HA setup configurations.

1) I have two Carp IPs on one interface /29.
So far no problem, the "problem" is, one IP is /30, the other one is /29.
Can this cause problems with a HA setup?

2.) Question two, why the question 1. only arises, pfsense has a nice "Troubleshooting High Availability" page with  "Common Misconfigurations".
Do these misconfigurations all apply to OPNsense as well?

The OPNsense wiki does not have such a list, I could not identify the question from 1.) as a problem, if it is a problem at all.

https://docs.netgate.com/pfsense/en/latest/troubleshooting/high-availability.html


Regards,

R1mSG

sorry, my question was misleading.
I am talking about updating via the terminal, not the GUI, the GUI works without problems.

The goal is to update minor/patches via CLI using the "opnsense-update" command.

Hey,

i have the problem that when I run an opnsense-update, I get a "Nothing to do." response.

If I run "/usr/local/opnsense/scripts/firmware/check.sh" or a pkg dry-run, it finds the updates (The GUI also shows updates).

The problem here seems to be a popup (every few updates this appears) in the GUI, as soon as I check for new updates and close this popup, the opnsense-update command works again.

You can solve the problem by running "pkg upgrade -y".
But here the question would be, if this command can lead to problems, because there is an extra official opnsense command "opnsense-update" for this, i would actually prefer to use the official command.

Is there a solution for this, or is it safe to update the Firewall via "pkg upgrade -y"?

Hey,

how can I check for updates via the CLI?
I would need the same function as under System: Firmware: "Check for Updates".

I have already tried with the following commands:
/usr/local/opnsense/scripts/firmware/launcher.sh check
/usr/local/opnsense/scripts/firmware/check.sh

The problem is that the new update 21.1 is not found at the end.
Somehow it only works via the WEB GUI.

---

OPNsense 21.7.8-amd64
FreeBSD 12.1-RELEASE-p22-HBSD
OpenSSL 1.1.1m 14 Dec 2021

Hey,

i wanted to investigate a HA/Carp problem, but I noticed in the dmesg.today logs that even with working firewalls, where I know of no problems, there are a lot of "state changed to" messages.

Is this a normal behavior for HA setups? (see attachment)

No hardware changes or updates were made during this time. Therefore the link state change should not come from that.

---

Hardware:
OPNsense 22.1.2_1-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1m 14 Dec 2021

Hey,

we have three firewalls here that are connected to each other with a VLAN. Each firewall has a MultiWAN configuration. One firewall is the main firewall. The two secondary firewalls have as default gateway the VLAN to the "master" firewall and as fallback connection a normal internet connection via a FritzBox.

Since the update to 22.1.1_3 we have problems with ssh connections to this two firewalls. But if we use the main firewall as jumphost, this problems does not exist.

These problems look like this:
When trying to download a file via scp (over the FritzBox WAN) from the "two" firewalls, the download stops in the middle. But uploading files to the firewall via scp works.
Likewise, if you connect via SSH and want to output a larger file with cat/tail, the connection breaks. Open via vim/less or even tcpdump output works without aborts.

Outputs of ssh/scp:
SCP:
   YYY:~# scp root@XXX:/conf/config.xml .
   config.xml                                                                                     
                                                                                   
   0%    0     0.0KB/s   --:-- ETAConnection to XXX closed by remote
   host. lost connection
   
SCP -vvv:
   debug3: send packet: type 1
   debug1: channel 0: free: client-session, nchannels 1
   debug3: channel 0: status: The following connections are open:
     #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1)

   debug1: fd 0 clearing O_NONBLOCK
   debug1: fd 1 clearing O_NONBLOCK
   Connection to XXX closed by remote host.
   Transferred: sent 2844, received 19476 bytes, in 0.2 seconds
   Bytes per second: sent 11404.7, received 78100.9
   debug1: Exit status -1

SSH -vvv:
   debug1: channel 0: free: client-session, nchannels 1
   debug3: channel 0: status: The following connections are open:
     #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1)

   Connection to XXX closed by remote host.
   Connection to XXX closed.
   Transferred: sent 3492, received 13244 bytes, in 6.7 seconds
   Bytes per second: sent 519.7, received 1971.0
   debug1: Exit status -1
   

We dont know if this could be a Problem with our MultiWAN configuration or anything else.

Is this problem known, or does anyone know something similar and can help us out here?


---

Hardware:
OPNsense 22.1.1_3-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1m 14 Dec 2021