After the update IPFire 2.29 (x86_64) - Core Update 188 I have problems with the VPN. I can no longer set up a host-to-network Virtual Private Network (RoadWarrior).
1 Like
It’s unclear from your first post. Did you have working Road Warrior setups prior to the upgrade that stopped working after the upgrade? Or are you creating a new Road Warrior user after the upgrade and cannot create the user?
More detail would help. What is actually happening compared to what you expect to happen?
Hallo @onitdev
Welcome to the IPFire community.
Are you saying that you are unable to enter any text in the cells labelled Name and Remark?
I have a problem when I want to create a new user, the lower section is missing.
Enter password etc.
the same picture as Orlando Ferreira.
1 Like
Sorry I missed what was being shown as being missed. It helps to explicitly state what is seen as not being right.
You should try and add a connection and when it fails with the page not showing everything that it should you should look at the end of the
/var/log/httpd/error_log
file and see what it indicates is going wrong on your system so that it stops after showing only a part of the page.
As shown in picture, I do not have access to sctions Authentication and Advanced client options, so it is not possible to configure new VPN client accounts.
Yes, I have working Road Warrior setups prior to the upgrade. I have two Road Warrior users created prior to the upgrade and working well. After upgrade it is not possible create new Road Warrior users.
The cells Name and remark are working well, but the remaining cells to configure user and button to finish are missing. The full form is shown in my screen shot.
The last two log lines in my ipfire shows this:
line 495.
[Wed Sep 18 16:07:05 2024] connections.cgi: Use of uninitialized value $dport_extra in concatenation (.) or string at /srv/web/ipfire/cgi-bin/connections.cgi line 412, line 495.
Undefined subroutine &General::getnextip called at /srv/web/ipfire/cgi-bin/ovpnmain.cgi line 572.
The error also occurs in IPFire 2.29 (x86_64) - Core-Update 189 Development Build: master/3cd62a7c
The following message appears in the file /var/log/httpd/error_log
Undefined subroutine &General::getnextip called at /srv/web/ipfire/cgi-bin/ovpnmain.cgi line 572.
Looking through the git repo history, the function getnextip was removed from the general-functions.pl file back in Core Update 186 as part of a cleanup operation to remove various functions/subroutines that were no longer being used.
It was obviously missed that there was one location still using that specific sub routine and it was obviously missed in all the testing of Core Updates 186 to 188.
I will discuss this with @ms later today.
2 Likes
After the update IPFire 2.29 (x86_64) - Core Update 188 from Core 186,
when I create new host-to-network and use a Static ip address from address pools I recive the follow error:
Hi,
As a temp solution edit /var/ipfire/general-functions.pl and add after line 450:
sub getnextip {
return &Network::find_next_ip_address(shift, 4);
}
sub getlastip {
return &Network::find_next_ip_address(shift, -1);
}
and save.
Hopefully one of the dev team can add the lines back in.
HTH
Joe.
No, we are not using getnextip, we are creating the code that makes sense for that part of ovpnmain.cgi
Hi Adolf,
Which is fine, either a fix or a rollbackin the meantime…
But whichever is better for the user.
At present OPENVPN is not working for users which is not good.
BR
Joe.
Rollback will not be done as that ends up with some people with the fix who upgrade after the fix is done and some not and also we can end up with a mixture of both versions out in the mirror servers which also is not a good idea.
The fix has been done and is merged into Core Update 189 which will be released for testing before too long.
If we did do a rollback the work to make sure that we did not create a problem by the rollback would probably take longer to do than issuing the fix in Core Update 189.
1 Like
I installed update 189. But it still doesn’t work.
I just updated a vm from CU188 to CU189 and yes, the problem is still there.
We tested the change on some CU 188 machines and it worked, so something must have been missed in the merging of the patch into the repo.
We will go and look at it.
This is the benefit of doing Testing.
Okay, it looks like, with all the changes we were doing, some in both CU189 (master) and in CU190 (next) we missed to add the change to CU189, although it is in CU190.
We will go and fix that.
I’m not seeing this in neither 186 or 187, for the record.