Test IPFire CU175

I cannot test N2N because I have no other server outside my local IPFire. But what is the normal condition?

The connection status should be visible.

1 Like

Okay. I think it’s a bug too :+1:.
I can only say that in theory.

1 Like

I did a test putting N2N values randomly, trying to recreate the error. Disconnected gives it to me. Possible?
I obviously cannot try to connect and disconnect.

By any chance, does it only do it to you after connecting/disconnecting?

Probably two bugs occur when IPFire is configured as an N2N client.

1 Like

Definitely so. I would like to recreate the errors, but if it is mandatory to have an external N2N server, I am afraid we will have to astect help from other users.
In the example I configured N2N client with random values.
I will follow up on the issue :wink:.

I confirm that it is a bug. I have the same problem. I was able to recreate the error!!! It occurs ONLY by importing the previously exported client package.

1 Like

Then I can understand what is happening here.

The bug fix for bug#11048 added pass or no-pass into the ovpnconfig file. For the Core Update code was put into the update.sh file to parse through the .p12 files in /var/ipfire/ovpn/certs and identify which are net, which will always be no-pass and which are host and identify those with a password and those without.

Importing a client package previously exported in an earlier Core Update will have the no-pass missing from the net2net entries.

I have realised that the same will happen with a restore of a backup from an earlier Core Update than 175.

There is another bug with the host entries that I have started to work on so I have requested that the patch set for fixing bug#11048 be reverted.
I will also think about how to check the ovpnconfig file restored from a backup and also any profile that is imported into IPFire and parse them to make sure that all of the entries either have pass or no-pass and not a blank entry.

1 Like

I imported the same package created with this trial version. That is, I created it(CU175), exported it, deleted it, and re-imported it. Does this have anything to do with the problem?

If all those steps were done with the same Core Update175 version then I would not expect a problem with the no-pass entry in the ovpnconfig file.

I will try and duplicate that myself.

Can you look in /var/ipfire/ovpn/ovpnconfig and see if there is a no-pass entry in the section immediately before the HOTP section.

It should look similar to
Screenshot_2023-05-20_18-05-50

Let me know if no-pass is present or if there is a null entry in that section.

If you create a new net2net profile, can you also check, before doing any export, if no-pass is present for that entry in the ovpnconfig file.

1 Like

I confirm that I have done all the steps with CU175. I am sending you the file…

/var/ipfire/ovpn/ovpnconfig

1,off,prova,prova,net,cert,,client,,192.168.9.0/255.255.255.0,,ipfire.localdomain,10.22.2.0/255.255.255.0,,,,,,,,,,,1024,on,1024,IPFire n2n Client,red,10.15.15.0/255.255.255.0,udp,1024,,1024,,,,,,,,SHA512,AES-256-CBC,disabled,HOTP/T30/6

That’s interesting. It has disabled. That field is obviously used for additional aspects on the net2net version.

Thanks for the input.

I will also try and duplucate it and find out where it is coming from.
Maybe once disabled it doesn’t get chsnged back to no-pass

1 Like

Happy to help :blush: !!!

If it helps, I changed “disabled” to “no-pass” and problem solved!!!

Changes made to /var/ipfire/ovpn/ovpnconfig

1 Like

Well that’s good in that it confirms that everything works when it is no-pass.

I need to find out the part of the code that puts in disabled and ensure it changes it to no-pass when it is enabled.

2 Likes

This must be related:

no-pass entries are in all ovpnconfig lines.

1 Like

I do not know if this is peculiar to CU175; I do not know if this is even a problem.
I zeroed the etags entries for my rule providers and then ran update-ids-ruleset at the console.
It looks like things are working okay with Suricata – rules are loaded and firing as expected.
However, running the update at the console gets this barf …

[root@ipfire suricata]# /usr/local/bin/update-ids-ruleset
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Invalid header block at offset unknown at /var/ipfire/ids-functions.pl line 550.
Couldn’t read chunk at offset unknown at /var/ipfire/ids-functions.pl line 550.
[root@ipfire suricata]#

Note: I have two rule set providers: Talos VRT rules with subscription and Emergingthreats Community Rules

1 Like

I suspect that by this you mean that you manually cleared the contents of the /var/ipfire/suricata/etags file from the command line.

I am not familiar enough with the perl code for the suricata cgi page and the other associated settings files but maybe other files also need to be modified if the providers are being deleted.

Why are you trying to do this via the command line rather than via the WUI.

Looking at line 550 in ids-functions.pl that code is related to the archive tarballs for the rulesets that have been downloaded. Probably when the provider is removed so is the ruleset tarball. You would need to read through the code to see what is being done when a ruleset provider is removed.

1 Like

One other thing I have noticed is that not all providers end up with an entry in the etags file.

I had Emerging Threats and Abuse.ch and both had an etag entry.

I then added Travis Green, Etnetera, Snort community and oisf traffic.

From these only Travis and oisf traffic ended up in the etags file. Snort community and Etnetera did not.

I did not actually remove anything. I simply edited the etag entries so their value would be out-of-date.thereby forcing a download of the rule files when running the update from the console.