Created attachment 1451 [details] This shows the result at the n2n client end When I did the fix for bug#11408 it looks like I put the pass/nopass entry for net to net configurations into a variable key number that is also used by some other entries. This means that when the configuration file is uploaded some entries end up overwriting the pass/nopass entry and this means the code does not know which icon to use or how to place the Status cell. I found this when testing out CU183 Testing but it was already present in CU182. Basically this problem has been present since CU181 when the fix for bug#11408 was released. I though I had tested out the n2n configuration but obviously not well enough. This is just a visual effect in not being able to see the status on the client end. I have confirmed that the n2n tunnel works without any issues. I will pick this up and find the solution and submit it.
What I should also have said is that any existing n2n client connections work fine. The problem is only if a new n2n client is uploaded. Maybe that is where I missed it as I checked out that the existing n2n client end was working fine but did not upload a new n2n client configuration.
I have identified what the problem is. In ovpnmain.cgi at line 3475 there is a line of code for the n2n config $confighash{$key}[41] = 'disabled'; That line has been there for a long time looking back through the Core Updates. but the disabled setting in key 41 has not been used. However {$key}[41] is used for defining pass or no-pass for if the certificate has a password and is secure or no password and is insecure. From bug#11408 no-pass was added in not just for the Road Warriors but also for the Net 2 Net configs. That line of code was missed when doing that bug fix. For any existing n2n connections the update added in no-pass into that key. However if a new n2n config is uploaded into the client end then key 41 is set to disabled but all the code is only looking for pass or no-pass. The simple fix is to change that line from disabled to no-pass. As that section of code only deals with n2n configs there is no need to check if the certificate has a password or not as all the n2n configs have no password. I made the change and tested it out and it has worked. I will now submit a patch fix for this.
Patch fix submitted to dev mailing list and patchwork. https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/thread/V25UHWYLX4F7DPIJYLNR742ZZBQJNGLI/ https://patchwork.ipfire.org/project/ipfire/list/?series=4166
Patches have been merged into next which will become CU185 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=4a0648243b991b00130aca4fcc615e717ddb1003 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=6dac44d40c4e1e80c497959f7098158462b033cb
CU185 Testing has been released https://www.ipfire.org/blog/ipfire-2-29-core-update-185-is-available-for-testing
Tested out on CU185 Testing the import of a N2N file into the client end and it worked without the original problem that this bug was raised for. This verifies that the bug fix has worked.
https://www.ipfire.org/blog/ipfire-2-29-core-update-185-released