Messages

I can confirm. Using HA-Proxy, kea, wireguard and freeradius.
Everything works after updating.

Thanks a lot to the developers!

Now I have also found the switch ;-)
Yesterday I was not so successful ...
Problem solved.

Cheers,
MiRei

Perhaps I have not described my problem clearly enough.
By the console I meant the serial interface or the VGA terminal.
In the event of a fault, I may no longer have a network interface and
therefore no correct time in the system.
I have not yet discovered the place in 25.1 for the configuration so
that I can only log on to the terminal with a password.

Thanks a lot!

Cheers,
MiRei

I have a little problem understanding your reply.
Do you mean ssh-copy-id ?

Cheers,
MiRei

I have just installed version 25.1 and all services and functions work without any problems. I really like the new dark theme.

Thank you very much for the great upgrade!

I noticed one small point: If OTP is set for authentication, the OTP code is now also required on the console to log in. If the system has a fault and does not receive a valid time, it is no longer possible to log in on the console. In the previous version, there was a switch "Disable integrated authentication" in the Administration - Settings Authentication under the servers. By activating it, you could log on to the console without OTP. Is there another way now?

Thank you very much!

Many thanks for the great work done in this project!

In ISC DHCP it was possible to activate "Deny unknow Clients" and "ARP-Table".
Will there also be this possibility in KEA in the future ?

Thank you for the update.

Now I can leave the server entry in the overwrite rule blank and it works.
Unfortunately, the overwrite rule does not work if the server field contains
the instance for which this rule is actually created.

Thanks a lot !

After installing a fresh OPNSense on a another allpiance I did following:

- created openvpn-instance
- created overwrite rule and select the created server-instance (no slash was in the list)
- the result was overwriting did not work

- then I created a server and delete it immedeately
- now the was a slash in the server-list of the overwrite rule. I selected the slash and the overwrite works.

Thanks a lot.

I have found a solution.
In the overwrite, under Servers, you must not select the intance for which the overwrite should apply.
It works if you select the "/" instead.

For openvpn with intances, client overwrite is not attracted. In the log I can see that the name is correct on the connection, but the client does not get the correct IP. I have already adjusted the overwrites and would expect the client to get the IP from the "IPv4 Tunnel Network" field.

With the revocation-list the blocking works immediately if I enter the above mentioned commonname. Then the client can't connect anymore.

Thanks a lot.

I have a problem with the API of the Haproxy.
The modification of conditions and e.g. the status query via

curl -k -u $OPNS_KEY:$OPNS_SECRET https://$IPFW/api/haproxy/service/configtest

work without any problems.

But when I want to to apply my modifactions via:

curl -k -u $OPNS_KEY:$OPNS_SECRET https://$IPFW/api/haproxy/service/reconfigure

I get an error message:

{"status": "failed"}

Does anyone have a tip?

Thanks a lot

With version 22.1.9(_1) our DHCP-V4 server crashes permanently. The hanging DHCP process could only be terminated via the console with kill -TERM $PID.
Only a downgrade with opnsense-revert -r 22.1.8 isc-dhcp44-server could restore stable operation.

We use an HA configuration. This behaviour was identical on the MAster and the slave.

Best regards

In the livelog I can find the rid (fae559338f65e11c53669fc3642c93c2) that lets 443 through.

On the console I'll get:
pfctl -sr | grep fae559338f65e11c53669fc3642c93c2

the following output:
pass out log all flags S/SA keep state allow-opts label "fae559338f65e11c53669fc3642c93c2"

Unfortunately, this doesn't really help me.

Even if I add a block rule to "any" in the ruleset of the network,
communication via port 443 is possible.
There is no manual floating rules that allows port 443.

With our installation of OPNSense 22.1.3 and 21.7.8, the automatic default deny rule did not work for port 443 any longer. The following entries appear in the LOG:

VL905 -> 2022-03-23T15:05:47 sourceip:54611 targetip:80 tcp Default deny rule
WAN <- 2022-03-23T15:05:44 sourceip:54612 targetip:443 tcp let out anything from firewall host itself

If you set up a new interface, a device can access to the internet via port 443 in this network, even though no FW rules have been created for it.
Does anyone have any idea what the reason for this could be?

Thanks, MiRei