NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
18:27:49
n2nNIBEn2n[15228]:
MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:2051
18:27:49
n2nNIBEn2n[15227]:
library versions: OpenSSL 3.4.1 11 Feb 2025, LZO 2.10
18:27:49
n2nNIBEn2n[15227]:
OpenVPN 2.5.10 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 20 2025
18:27:49
n2nNIBEn2n[15227]:
WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure
18:27:49
n2nNIBEn2n[15227]:
Cipher negotiation is disabled since neither P2MP client nor server mode is enabled
First question:
Found /var/ipfire/ovpn/openssl empty.
Is this normal? Github leads me to think there should be a file called ovpn.cnf.
Copied file from Github, set permissions nobody:nobody.
n2n did not come back.
Second question:
As mentioned above:
I installed core 192 from scratch on new rpi 4b 8 GB at client side n2n… Restored backup created on core 190 with another rpi 4b.
Transferred certs from n2n server to client.
Reason: server certs were not restored on client when I restored my backup on core 192. Backup was created on client running core 190.
n2n server still runs core 190.
Do I have to renew the certs on n2n client (192 with new hardware) and transfer them to server (190), too?
Third question:
If this trouble is caused by missing file /var/ipfire/ovpn/openssl/ovpn.conf on server:
Does ovpn n2n server block a client after too much retries?
There is an option in n2n.conf to restore lost connections so it should not.
Guardian an others are not on duty.
The ovpn.cnf file was in /var/ipfire/ovpn/openssl/ until CU185.
From CU186 it was moved to and the name changed to usr/share/openvpn/openssl.cnf
So you shouldn’t have an empty ovpn.cnf file in /var/ipfire/ovpn/openssl/ you shouldn’t have any file in there.
I don’t have any file in that location in any of my IPFire systems, both physical and virtual.
I tested my n2n setup with CU192 at both ends and the n2n connection worked without any issues.
I will look at setting up a situation with CU192 installed from scratch and then a backup from CU190 restored at one end and CU192 at the other end also with a restore from CU190 to see if I can reproduce what you are describing. Hopefully I can do this tomorrow or on Tuesday depending on my availability.
I am not sure why you have done the restores from CU190.
I have a virtual system with both ends that were at CU191 and n2n was working and both were updated to CU192 and n2n worked without any other restore necessary.
Your ovpn log does not show any message that indicates that something stopped working.
That file is not missing. It was moved to another location, and the name changed,back in CU186.
My systems are all using the file in the new location.
I will come back with my results from trying to reproduce your version installation and backup restore as soon as I am able to.
Ovpn sits and waits until friday on client (192) and server (190) side, logging: “retrying…” as copied from logs above.
Transferred certs for n2n again.
I don’t understand why it worked since january (both 190) and came back after automatic rebooting of both ipfire rpi’s every night, but let me check firewall rules just to be sure.
I am not sure what you mean by ovpn extended screen.
If you mean the button named “Advanced server options” then that screen only applies to the Road Warrior configuration. Nothing in there applies to Net to Net.
Firewall Rules (My forward Policy is set to Allowed not Blocked, so I have no firewall rules for OpenVPN N2N.
Static routes wui screen.
I don’t use static routes so this screen is empty in both server and client ends.
My two N2N ends are virtual machines that are connected to the green side of my production IPFire. That production IPFire gives all the info required for each of the N2N machines to contact each other.
cli routing table for server
default via 192.168.26.254 dev red0 proto dhcp src 192.168.26.200 metric 1002
10.110.30.0/24 via 10.110.130.2 dev tun0
10.110.130.0/24 via 10.110.130.2 dev tun0
10.110.130.2 dev tun0 proto kernel scope link src 10.110.130.1
10.120.50.2 dev tun1 proto kernel scope link src 10.120.50.1
192.168.26.0/24 dev red0 proto dhcp scope link src 192.168.26.200 metric 1002
192.168.120.0/24 via 10.120.50.2 dev tun1
192.168.200.0/24 dev green0 proto kernel scope link src 192.168.200.254
192.168.220.0/24 dev blue0 proto kernel scope link src 192.168.220.254
192.168.240.0/24 dev orange0 proto kernel scope link src 192.168.240.254
cli routing table for client
default via 192.168.26.254 dev red0 proto dhcp src 192.168.26.220 metric 1002
10.120.50.1 dev tun0 proto kernel scope link src 10.120.50.2
192.168.26.0/24 dev red0 proto dhcp scope link src 192.168.26.220 metric 1002
192.168.120.0/24 dev green0 proto kernel scope link src 192.168.120.254
192.168.200.0/24 via 10.120.50.1 dev tun0
I confirmed that the connection is still working fine with CU192. ping works between a machine on the green network of the server IPFire and a machine on the green network of the client IPFire and vice versa.
I can also ssh connect from a machine on the server green network to a machine on the client green network and vice versa and can do any admin or data access that I want via the ssh connection.
I have not had time yet to create the n2n machines with different Core Update versions and see how that goes.
Since Core Update 61 the OpenVPN Management Interface is integrated into the OpenVPN WUI page to provide the status information for each connection.
In the configuration set up in IPFire the management interface information is only available for localhost and is provided to the WUI only.
The only way to stop this message would be to add a password in for the management interface which would mean that you get no status info for your connections, such as CONNECTED, DISCONNECTED, AUTH etc. Each time you would want to know what the status was you would need to enter a password to get the status information for that connection.
As it is local host only then it is only available to the IPFire system itself and to access it a user/attacker would have to be able to login to the IPFire terminal as root or be able to access the WUI, but then only for the status info shown in the connection status entries.
If you don’t specify a management port then it uses the Destination port by default. This is written alongside the Management Port entry box.
I have n2n set up in my vm testbed for testing and development purposes the default value seemed fine to me.
This is because the configuration file that is created in the zip file has the entry
script-security 2
which means that OpenVPN n2n is allowed to call built-in executables and user-defined scripts. The built in executables allowed to be called are programs such as ifconfig, ip or route.
If you don’t want to see that message then change the value in your conf file for both the server and the client from 2 to 0.
This value means Strictly no calling of external programs, so if you are happy with that then you can change the entry in the two conf files for the n2n connection.
