Messages

Dear All,

Using the 25 series, I did configure a small opnsense-device as a Wifi Acess point using EAP-TLS authentication with client certificates an an external Freeradius server.

After upgrading to 26.1, the EAP-TLS onfiguration is gone for the Wifi interface. In the Wifi interface, there seems to be no longer an option to specify EAP-TLS with a radius server of choice.

I did also install the community freeradius package locally, but I did not configure it, yet. Nonetheless, as field to enter a radius server IP does not seem to appear again in the Wifi interface settings.

Please point me to the right direction? Is the possibility to do EAP-TLS gone? In that case, I would use an external Wifi AP.

This is APU2 and wle200nx and the interface does not allow options other than Infrastructure /BSS) after the update.

Regards,

Michael Schefczyk

Please be so kind to take a look at this post:

https://forum.opnsense.org/index.php?topic=38742.0

Do you have recommendations regarding firewall rules?

Dear All,

Before upgrading to 24.1, I did use NRPE via the manually installed package. I had/have a LAN firewall rule pointing port 5666/tcp from the LAN network or address to "This Firewall".

After moving to the package, external calls to NRPE always generate: CHECK_NRPE STATE CRITICAL: Socket timeout after 10 seconds. I do not find relevant log entries on the firewall.

Connecting to NRPE set up to listen on port 5666 address 127.0.0.1 allowing the right hosts and allowing arguments. Two commands (check_users and check_load) are set up in the GUI.

When connecting to the firewall via SSH, everything does look quite good:
- Typing check commands (as root) does work well, for example /usr/local/libexec/nagios/check_users -w 5 -c 10
- /usr/local/etc/nrpe.cfg does contain a configuration matching what is set via the GUI and including nrpe_commands.cfg
- /usr/local/etc/nrpe_commands.cfg has the commands defined in the GUI

Probably the issue is to pick the correct listen address and to define the right firewall rule. Can someone help, please?

Regards,

Michael Schefczyk

This post (thanks!) is most helpful in pointing to NAT reflection checkboxes:

https://forum.opnsense.org/index.php?topic=8783.0

The documentation says on nat reflection in the context of port forwarding: "Leave this on the default unless you have a good reason not to." Maybe there is a compelling reason more often :)

Dear All,

My situation is two SOHO locations with a CARP/HA-firewall with double WAN in each location. In one location, one WAN connection does only provide a single fixed IP with no switching capabilities in the modem/connection device whatsoever. There, I have a pfSense box in front of the CARP/HA-firewall. I would like to migrate that box to OPNSENSE.

The box does basically have three rules:
- 1:1 NAT to expose the virtual IP shared by the HA-firewall members to basically all incoming traffic.
- respond to ping, ideally directly without any forwarding
- redirect one UDP-port to OpenVPN, if that should ever be needed to administer the box.

My bottleneck is the 1:1 NAT. I can get "respond to ping" working. As soon as I enter my 1:1 NAT rule (please see pdf enclosed), responding to ping does stop. However, the 1:1 NAT does work neither.

I am aware that computernala (https://forum.opnsense.org/index.php?topic=6860.0) links to instructions that outbound NAT should be set to hybrid. However, I am not certain as to which IP to enter where in the indivudual rules among the outbound rules. I did not find a working combination.

Could someone please be so kind to point me to the right direction? If necessary, probably the target device (192.168.0.2) could execute the ping responses. If the openvpn rule is not possible, I could live with that.

Unfortunately, pfSense rules are no longer importable at OPNSENSE. Hence, I need to start from scratch.

Thanks & regards,

Michael Schefczyk

If I interpret pfSense's marketing communications correctly, they are implying that emphasis on pfSense CE will be reduced and QuickAssist support will be among the first features reserved to pfSense Plus.

While I very much like both pfSense and OPNsense in terms of the software published, I think that a good strategic response by OPNsense might be to offer QuickAssist support for some relevant platforms (e.g., Xeon D and C3000) to the general public.

The resulting combination of relevant features (faster HA Proxy and VPN cryptography) on one side and less emphasis on the other side might lead to larger portions of the general public / community making informed choices.