158 (beta): Uploading OpenVPN client package results in error message

I just now got that error trying to import a net to net connection in openvpn at the moment in version 158. Like you, I do not see anything in the logs.
After reloading version 152, the n2n connection imported just fine.

I’ll also add to this, yesterday, I took a new firewall to someone and upgraded from 32 to 64 bit. The ONLY thing other than the graphs (a known fixable issue) that failed was the VPN. IPfire showed connected, but it simply would not work. Wen’t thru the troubleshooting logs etc and never did find the issue. Finally reloaded the firewall to version 152, and rebuilt all by hand, and it’s working great!!
I believe version 158 may have and issue with openvpn that I am not finding…

Hello.
I have a similar problem.
In my case: fresh install 157 and upgrade to 158

I add OpenVPN Net-to-Net testn2n connection on “ipfire server”

After the first upload on “ipfire client”
[Net-to-Net Virtual Private Network (Upload Client Package)]
image

and in the folder /var/ipfire/ovpn/n2nconf the folder testn2n appears,
and in this folder the file testn2n.conf

After second upload the same configuration file .zip

image

“*.conf move failed: Inappropriate ioctl for device”
image

After unzip configuration .zip file
image

and zipped
image

image

Error messages
Filecount does not match only 2 files are allowed
image

In /var/log/httpd/error_log

format error: can't find EOCD signature 
 at /usr/lib/perl5/site_perl/5.32.1/Archive/Zip.pm line 1090.
	Archive::Zip::Archive::_findEndOfCentralDirectory(Archive::Zip::Archive=HASH(0x34707e0), IO::File=GLOB(0x3476c48)) called at /usr/lib/perl5/site_perl/5.32.1/Archive/Zip.pm line 966
	Archive::Zip::Archive::readFromFileHandle(Archive::Zip::Archive=HASH(0x34707e0), IO::File=GLOB(0x3476c48), "/tmp/_jdhY0V1Bu") called at /usr/lib/perl5/site_perl/5.32.1/Archive/Zip.pm line 940
	Archive::Zip::Archive::read(Archive::Zip::Archive=HASH(0x34707e0), "/tmp/_jdhY0V1Bu") called at /srv/web/ipfire/cgi-bin/ovpnmain.cgi line 3321

edit
content testn2n.conf from server

# IPFire n2n Open VPN Client Config by ummeegge und m.a.d
# 
# User Security
user nobody
group nobody
persist-tun
persist-key
script-security 2
# IP/DNS for remote Server Gateway
remote xxx.dydns.net
float
# IP adresses of the VPN Subnet
ifconfig 10.0.111.2 10.0.111.1
# Server Gateway Network
route 10.0.11.0 255.255.255.0
# tun Device
dev tun
#Logfile for statistics
status-version 1
status /var/run/openvpn/-n2n 10
# Port and Protokoll
port 1196
proto udp
# Paketsize
tun-mtu 1500
fragment 1300
mssfix
remote-cert-tls server
# Auth. Client
tls-client
# Cipher
cipher AES-256-GCM
pkcs12 /var/ipfire/ovpn/certs/testn2n.p12
# Debug Level
verb 3
# Tunnel check
keepalive 10 60
# Start as daemon
daemon testn2nn2n
writepid /var/run/testn2nn2n.pid
# Activate Management Interface and Port
management localhost 1196
# remsub 10.0.0.0/255.255.255.0

content /var/ipfire/ovpn/n2nconf/ testn2n.conf
after first import with error

# IPFire n2n Open VPN Client Config by ummeegge und m.a.d
# 
# User Security
user nobody
group nobody
persist-tun
persist-key
script-security 2
# IP/DNS for remote Server Gateway
remote xxx.dydns.net
float
# IP adresses of the VPN Subnet
ifconfig 10.0.111.2 10.0.111.1
# Server Gateway Network
route 10.0.11.0 255.255.255.0
# tun Device
dev tun
#Logfile for statistics
status-version 1
status /var/run/openvpn/-n2n 10
# Port and Protokoll
port 1196
proto udp
# Paketsize
tun-mtu 1500
fragment 1300
mssfix
remote-cert-tls server
# Auth. Client
tls-client
# Cipher
cipher AES-256-GCM
pkcs12 /var/ipfire/ovpn/certs/testn2n.p12
# Debug Level
verb 3
# Tunnel check
keepalive 10 60
# Start as daemon
daemon testn2nn2n
writepid /var/run/testn2nn2n.pid
# Activate Management Interface and Port
management localhost 1196
# remsub 10.0.0.0/255.255.255.0
# Logfile
status-version 1
status /var/run/openvpn/testn2n-n2n 10

content /var/ipfire/ovpn/n2nconf/testn2n.conf
after add connect in WUI
add Net-to-Net Virtual Private Network

# IPFire rewritten n2n Open VPN Client Config by ummeegge und m.a.d
#
# User Security
user nobody
group nobody
persist-tun
persist-key
script-security 2
# IP/DNS for remote Server Gateway
remote xxx.dydns.net
float
# IP adresses of the VPN Subnet
ifconfig 10.0.111.2 10.0.111.1
# Server Gateway Network
route 10.0.11.0 255.255.255.0
up "/etc/init.d/static-routes start"
# tun Device
dev tun
#Logfile for statistics
status-version 1
status /var/run/openvpn/testn2n-n2n 10
# Port and Protokol
port 1196
proto udp
# Paketsize
tun-mtu 1500
fragment 1300
mssfix
remote-cert-tls server
# Auth. Client
tls-client
# Cipher
cipher AES-256-GCM
pkcs12 /var/ipfire/ovpn/certs/testn2n.p12
tls-version-min 1.2
# Debug Level
verb 3
# Tunnel check
keepalive 10 60
# Start as daemon
daemon testn2nn2n
writepid /var/run/testn2nn2n.pid
# Activate Management Interface and Port
management localhost 1196

Maybe someone will find a solution.

This is also present in 159.

I have just searched through the IPFire Bugzilla from start of July to current date and no bug has been raised for this issue.

Please raise a bug for this issue. Your IPFire People email address and password also work as credentials for logging into IPFire Bugzilla.
https://bugzilla.ipfire.org/

The wiki provides guidance on submitting a bug and how to write a good bug report
https://wiki.ipfire.org/devel/bugzilla

1 Like

Bug raised:
https://bugzilla.ipfire.org/show_bug.cgi?id=12668

2 Likes

Workaround for this:

After the failed upload, verify that the directory /var/ipfire/ovpn/n2nconf/YOURN2NPACKAGENAME exists, with a .conf file in it

Copy the cert in the package to /var/ipfire/ovpn/certs

Change owner/group of the cert to nobody/nobody

Then edit /var/ipfire/ovpn/ovpnconfig and add a new line, copying one already present and changing it is best. Do note that the lines are not in order: the first number is incremental, you must find the highest linenumber and add 1. Then modify the line with the correct values for your networks. Disable and enable the connection and you should be up.

2 Likes

I tried a other workaround:

  1. I added OpenVPN Net-to-Net testn2n connection on “ipfire server”.
  2. Downloaded and unziped Client Package from “ipfire server”.
  3. I added and properly configured the connection testn2n as a client on “ipfire client".
  4. I replaced testn2n.p12 file from Client Package
    in /var/ipfire/ovpn/certs/ on “ipfire client".

It looks like it works.

2 Likes

Could not quite get tphz’s solution to work. However, going from the entry above that, I then:
Replaced the .conf file in /var/ipfire/ovpn/n2nconf/ with the one downloaded in the Client Package
And it worked!!! yeah!!!
Can keep my job now… :slight_smile:

2 Likes

Yet another new install. Same issue on Core Update 159
However, one more step needed.
After I copied the two files over, I edited the connection on the client, changed nothing and hit save.
It is now connecting…

3 posts were split to a new topic: Help me out with an example string for /var/ipfire/ovpn/ovpnconfig

This same issue with Net2Net connections still exists in Core 160.

Has anyone come up with a definitive procedure to use as a workaround?

BTW - RoadWarrior connections work correctly.

For me the only workaround for now is to install core 157, add the connection, and then upgrade.

There are not updates in the bug report: 12668 – Adding a OpenVPN n2n client package generates errors and fails

Is this being treated as a bug?

I think Its a restore issue ( cross versions) I had a similar issue I had an old backup from about 152 and following a hard disk dying I reinstalled tried to use a 152 backup to load on a 159 (I think it was) everything restored nice but OVPN would not play the logs was giving errors about errors in the keys etc etc ,I ended up removing the OVPN and all the existing certificates etc and i then re added it as I only had two users

I have tried this with 158 and 159 (not 160 yet), both (client and server) in the same version, and both installed from scratch in a test environment (virtualbox).

The only thing that has worked for me is to install the server in latest version (eg. 159), and then install 157 in the client, add the connection, and then upgrade.

Yes, on Core 158, Core 159, and Core 160 the automatic Net2Net set up is broken. The only hope you have is to try to do some kind of manual setup.

The Road Warrior set does work correctly on all of these versions.

Fred

Thanks everyone for pointing this out as a bug - saved me a lot of time and frustration trying to figure this out. A real shame considering Roadwarrior is trivially easy to set up and works great.

My first donation to the project will arrive as soon as the Net2Net bug is fixed :cowboy_hat_face:

A patch for the bug was merged into next and master 4 days ago and so is now available in Core Update 161 Testing release.

It would be good if someone who has the ability to evaluate the testing release for the n2n setup could carry out a test of it to confirm that it is working as expected.

Confirmed, 161 Testing Release imports the client profile properly.

3 Likes

It does appear to work as expected now.

Best regards,
Fred

2 Likes

“Upload Client Package” to Core Update 161 (testing version)
from Core Update 160 and Core Update 161 (testing version) -
looks like no error.

However, there is a little “but” :face_with_hand_over_mouth:

On OpenVPN server → msfix=0

on WUI

image

and in .conf file, in client package file
image

But
After upload to OpenVPN client → msfix=1

image