CU197 to CU200 ovpnmain.cgi creates invalid N2N config: Oops, something went wrong... Invalid key

VPNs OpenVPN
1

CU 201, cgi-bin/ovpnmain.cgi - I followed www.ipfire.org - OpenVPN Configuration and added a new Net-to-Net connection machine2machine with remarck with a typo in it, saved it. The new N2N connection it is displayed in section Connection Status and -Control.
I clicked “Edit” on newly created config to correct the typo in connection Remark.
This action generates error message

Oops, something went wrong…

  • Invalid key.

image

From what I see on disk the subfolder along with connection.conf are created under /var/ipfire/ovpn/n2n/ (and the conf file contains the typo Remark). Not that a big issue so I’ve downloaded the Client package (.zip file), went on the other side (cu200), imported it (via Net-to-Net Virtual Private Network (Upload Client Package) and got the message:

Error messages

Filecount does not match only 2 files are allowed

image
image1012×242 9.48 KB

Inside tmp the upload generated this file which is the zip I’ve uploaded via the UI

ll -t /tmp | head -n 2
total 20
-rw------- 1 nobody nobody  624 May 19 21:26 UY6RnD14iq

gunzip -l UY6RnD14iq
         compressed        uncompressed  ratio uncompressed_name
                629                 624   3.8% UY6RnD14iq

But the gunzip can’t uncompress that file:

gunzip UY6RnD14iq
gzip: UY6RnD14iq: unknown suffix – ignored

mc displays a different story:

image
image640×146 13.4 KB



file UY6RnD14iq
UY6RnD14iq: Zip archive data, made by v2.0 UNIX, extract using at least v2.0, last modified May 19 2026 21:04:50, uncompressed size 828, method=deflate

What do I need to change in my process in order to build a N2N connection?

2

This needs to be solved first before trying to use the zip configuration file.

This message means that something is wrong with one of the elements of the connection configuration.

Can you indicate what the typo was? If it was just a wrong letter or digit then that would not create any issue but if it was the use of a special character then it might cause the separation of the n2n connection configuration into the hash array to be done incorrectly.

If it was just the use of an “s” instead of a “b” in the remark then there must have been some other issue in the creation of the connection.

Looking at the code then potentially even trying to remove that connection giving the problem will fail to occur as the contents of the hash will also be incorrect for what ever reason when it works to remove that connection.

Will probably require to look at the contents of /var/ipfire/ovpn/ovpnconfig to try and figure out which entry is incorrect. That will involve a bit of work as the entry is used for both RW & N2N entries and is just comma delimited and you have to look at the code to see what each entry should be containing.

As an example here is the entry for my testbed setup for n2n

3,on,ipfirenet2net,ipfire,net,cert,,server,,192.168.180.0/255.255.255.0,,ipfire2.local.net,192.168.135.0/255.255.255.0,,,,,,,,,,,3120,on,1300,ipfire to ipfire2 net2net,red,10.120.50.0/255.255.255.0,udp,3120,,,,,,,,,,,AES-256-GCM,no-pass,HOTP/T30/6

The first section content of 3 means this is the 3rd entry in the file as there are two other RW entries.
The on means that it is enabled.
The ipfirenet2net is the name of the connection.
The “ipfire to ipfire2 net2net” entry is the remark.

I just tested out putting a comma in the remark and the connection was saved. When I then tried to edit that connection I got your “Invalid key” error message.

The good news is that selecting the dustbin symbol to remove the connection was successful.

That definitely looks like a bug that a comma is accepted for the remark, especially when the file it is saved to is a comma delimited file.

3

Yes, this type of typo.

Delete icon does its job: conf file and folder are gone.

Editing the conf file with nano is an acceptable workaround for Remark.

But the fact that import of client config fails is a show stopper.

[quote=“Adolf Belka, post:2, topic:15801, username:bonnietwin”]

When I then tried to edit that connection I got your “Invalid key” error message.

[/quote]

I have only one n2n connection, no comma (or any special characters) in its name. Remark contain only letters and spaces.

Any attempt to edit it generates the invalid key message.

Not a problem - I can edit it manually with nano…or erase it and create it from scratch (paying attention to what I type)

4

Any solution to have a valid .zip client config for OpenVPN N2N?
As I said, I can edit N2N .conf file content it manually (via nano) if there is a missing element in it (that UI does not add/generate).

For what is worth some 2+ years ago the UI was generating correctly the N2N config files…

LATE EDIT: no matter how many times I erase and create N2N the config file is broken: trying to edit it generates the error.
Workarround: activate and deactivate the N2N - this eliminates 2 commas (,) in the /var/ipfire/ovpn/ovpnconfig file - after that the UI can edit that config.

Bug?

5

It looks like it is some form of bug.

The issue has been present since CU197 when the changes for OpenVPN-2.6 were introduced.

When the code changes were made they were focussed on the Road Warrior with the aim to not change anything related to the Net to Net.

For existing Net to Net connections everything works fine but for newly created ones from CU197 onwards there are changes to the n2n configuration file created that as far as I am aware were not intended.

I have confirmed this by testing with CU197 and CU196. The issue is seen for the first time at CU197.

I also confirm that by disabling and enabling the connection a few times then you can edit the connection.

However I have not yet checked that the config file that is created for transfer to the client end of the n2n tunnel is correct or if it has some of the changed or added lines that I found earlier.

It seems that you are the first person to try creating a new net to net connection in the 6 months since CU197 was in testing/released.

6

I have checked this now and the config file created to transfer to the client end of the n2n tunnel is correct.

So the change is that somehow when creating a new n2n connection the ovpnconfig file entry has some differences.

I will now check what those differences are when I can make some time.

7

I confirm that after 1-2 enable-disable, the client config is safely exported, can be imported on “the other side” and N2N tunnel works flawlessly!

As you already pointed out, old n2n connection just work fine so the need to create a new one is limited.

Thank you for helping me!

As far as AI say (sorry, but counting commas is not my strong point) the new N2N has 2 (two) additional comma at the end of the line. Unless AI counts oranges as apple (which happened before).