Messages

Just for curiosity I also tried the options "ipv6" and "!ipv4" at the same time which yields to an error in the logfile. I'm also confused by the label in the menu, stating these two are "(default)" options.

With the legacy setup of OpenVPN one had the option to enable resp. disable "Redirect Gateway" with a toggle.

In the new instances implementation it's instead a list of options. My question is:

Is "Redirect Gateway" now always active and one can only select the required option(s), or will "Redirect Gateway" only be active, if at least one option is selected? Chosing "default" does not seem to the have same effect as ommiting all options but specifying --redirect-gateway on its own according to OpenVPN's documentation.

-- Reuti

Hash collisions are not as important with HMAC for large (>=128 bits) authentication tags. HMAC-SHA1 at 160 bits is still considered secure. HMAC-SHA-512 would waste CPU resources since HMAC runs the hash function twice per message, and OpenVPN would do it for every sent and received packet. Calculating SHA-512 might also have a significant performance impact (CPU and throughput) on the client side.

Thx for the pointer. I used a former guide to set up OpenVPN which (like several others) was suggesting to use SHA-512, which is obviously for this use case superfluous.

-- Reuti

After converting my OpenVPN setting to the new instance based setup, two questions remain:

a) The new default for authentication seems to be SHA1, when I would like to go to my former setting SHA-512 I have to enable "advanced mode" – is this intended?

b) When "Enforce local group" is left to "none" it's working fine. If I select a defined group "remote" for the remote users it states in the log file "OpenVPN '2' requires the local group 2001. Denying authentication for user X", despite the fact that user X is a member of group "remote".

-- Reuti

There seems to be a deadlock situation, in case "System" => "Firmware" => "Status" shows no output. Presumably as pkg.opnsense.org maybe down or can't be accessed, then this dialog will never show any ouptut.

As a result, also the "VPN" => "OpenVPN" => "Client Export" shows no "Remote Access Server" or "Linked Users" at all.

After waiting 2 days, now the above functions are working again at both of my locations (different towns, different networks).

-- Reuti

Hi All,

I recently updated OPNsense to 21.7.3_3. Now I face the issue, that "VPN => OpenVPN => Client Export" doesn't show any linked users any longer. This might be the result, as already the first field "Remote Access Server" does not list the local OpenVPN server. Even entering the name shows only that it can't find it: 'No results matched "..."'

I have two OPNsense servers running and both face the same issue.

Nevertheless: already exported users are still able to connect to OpenVPN.

Did I miss any new setting which is required to use this export of the certificates of the server and user now?

-- Reuti

Hi Franco,

Thx for the advice. But the output of the 20.1.8 patch was to adjust this file, kill the syslogd and start (at least one time) syslog-ng by hand.

Should the output of the update procedures in general be ignored?

I also installed just postfix and there were also some instructions for actions to be taken. Shall I ignore them or follow them?

-- Reuti

Code Select Expand

Message from syslog-ng327-3.27.1_1:

--
syslog-ng is now installed!  To replace FreeBSD's standard syslogd
(/usr/sbin/syslogd), complete these steps:

1. Create a configuration file named /usr/local/etc/syslog-ng.conf
   (a sample named syslog-ng.conf.sample has been included in
   /usr/local/etc). Note that this is a change in 2.0.2
   version, previous ones put the config file in
   /usr/local/etc/syslog-ng/syslog-ng.conf, so if this is an update
   move that file in the right place

2. Configure syslog-ng to start automatically by adding the following
   to /etc/rc.conf:

        syslog_ng_enable="YES"

3. Prevent the standard FreeBSD syslogd from starting automatically by
   adding a line to the end of your /etc/rc.conf file that reads:

        syslogd_enable="NO"

4. Shut down the standard FreeBSD syslogd:

     kill `cat /var/run/syslog.pid`

5. Start syslog-ng:

     /usr/local/etc/rc.d/syslog-ng start


Hi,

Indeed, that did the trick. Now the syslogd doesn't start any longer by default but the syslog-ng.

Thx

-- Reuti

Hi,

With one of the last updates to 20.1.8 IIRC in the output of the patch procedure the steps were listed to get now syslog-ng as new default in OPNsense working. With the update to 20.7, now syslogd does get started as default again. I have two questions regarding this behavior:

• Is syslog-ng the official log daemon in OPNsense, or is it just a matter of taste which to prefer?
• Even with /etc/rc.local in place, syslog-ng is not started by default but syslogd. How can I make syslog-ng the default again?

Code Select Expand

root@opnsense:/etc # cat rc.conf
syslog_ng_enable="YES"
syslogd_enable="NO"

Kind regards -- Reuti