Thank you very much for explaining this.
Yes, I know, but that’s not what I wanted to show/ask.
Why
After importing a new connection on the client side, the Name aatestn2n (Expired) is displayed.
edit
Could someone please do this test?
1 Like
I’m trying to try it myself. But I’m not sure I can. N2N never used. I currently use “the other kind.” I also need to get organized on the client side.
Are you okay with CU173?
With CU174 I can’t do that at all. I installed the test version of IPFire on the virtual machine. I would have to open an almost impossible to do “port forward”.
I guess I can’t help you for now. I am encountering too many difficulties 
.
I have to learn how to set up this kind of VPN first.
It is with the severe English deficiencies I have, it will be a long time before I understand how it works .
Let’s hope for help from other users.
Don’t give up 
wiki.ipfire.org - OpenVPN Configuration
wiki.ipfire.org - Append a network-to-network connection
BR
1 Like
Thank you very much. I will study these pages. I am sure I can do it and I am sure it is not even complicated to do it with IPFire. As mentioned though, since this is something new to me, it will take me quite a while to understand it well. Perhaps by the time I am ready, the stable CU174 will be out 
.
I can help you with “host-to-net”. For this one I became an expert in doing it with IPFire.
But I think it doesn’t fit for your case.
You are welcome, this one is old and have nothing to do with Core 174. The displayed status reads out the signals from the OpenVPN management interface → git.ipfire.org Git - ipfire-2.x.git/blob - html/cgi-bin/ovpnmain.cgi whereby a “CONNECTED” checks if an “Initialization Sequence Completed” message appears. This is a localhost check while startup (configuration at a first glance) but an expiring certificate will at least catch up if a client connects (appears after the Initialization Sequence Completed message). Even if a connection won´t come up after you disabled the checkbox and htop should confirm this (first problem from above), the status flag should look in this case better but may this come up in another topic since it is OT in my opinion here and does not touch the openvpn-authenticator problem.
Best,
Erik
EDIT: @tphz sorry i have misunderstood your statement from above and thought of another problem. Have seen that the “(expiring)” hint is indeed a part of Core 174 → git.ipfire.org Git - ipfire-2.x.git/commit so this might be a bug if your certificate is new and not expired… will go also for a checkout.
4 Likes
My guess is that you are an expert in VPN.
How exactly does N2N work?
I was able to configure N2N in IPFire, but I have “host-to-net” in mind and I can’t even understand the logic of how N2N works.
Penalized by not knowing English, I need a few lines summarizing everything. Suggestions?
the logic is that with N2N, you connect two routers with each other, so that both sub-nets would be joined together. If you have an organization with 2 offices each one with their own Lan, with a N2N connection between the two routers, you create a virtual Lan allowing each individual computer in each office to communicate with everyone else.
A roadwarrior connection on the other end, will connect one machine to the router of a distant organization. Like when a person connects from home to the office router to work remotely.
A third case is having booth: a roadwarrior connection where the person working from home connects to office A, AND because office A is also connected to office B, he/she can connect also with the network in office B. If for example you have a print server in Office B, you can send a document to this server by connecting host-to-net to office A, which is connected N2N with office B. This creates two separate but connected tunnels
I II
home--->|office A|===>|office B|---print server
3 Likes
I thank you infinitely for the clarification.
I may have an idea.
Basically it is a matter of “unifying” two or more private networks scattered around the world by forming a single network.
I could, for example, make a whole network between my home, the school where I used to work and, why not, if I want, even between the network of a hypothetical friend of mine who lives in America.
So many users scattered around the world in one network. Interesting!!!
Obviously I can set rules in firewalls based on virtual IP.
As I currently do for my openvpn.
3 Likes
Hi all,
can confirm what @tphz wrote above if an N2N connection will be imported via " Net-to-Net Virtual Private Network (Upload Client Package)", it will be flagged as expired even the certificate has been created with a “Expires soon” . The problem appears to be have something to do with this patch git.ipfire.org Git - ipfire-2.x.git/commit .
Best,
Erik
5 Likes
That should be flagged up to the dev mailing list then as that is new in CU174 so would be good to get fixed before full release.
Maybe also raise a bug against it for CU164 Testing
3 Likes
@bonnietwin , i think i found the problem according to @tphz expiring date catch from above. The investigation of the certificate for the expiring date includes only *.pem files but an N2N client import includes only a *.p12 file and no *.pem . The OpenSSL command uses the x509 flag so it covers no PKCS#12 files but even if, the PKCS#12 container does not contain ‘Validity’ information.
Potential solution: ovpnconfig´s index contains “IPFire n2n Client” as a potential search string to investigate the connection name(s) which needs to be extracted into PEM format to read out the “Not After” line for calculation.
May someone can confirm ?
Best,
Erik
@tphz
if you want to check a potential solution for your problem above, does this →
for i in $(awk -F',' '/IPFire n2n Client/ { print $3 }' /var/ipfire/ovpn/ovpnconfig); do
openssl pkcs12 -in /var/ipfire/ovpn/certs/${i}.p12 -out /var/ipfire/ovpn/certs/${i}cert.pem -nodes -password pass:''
chown nobody:nobody /var/ipfire/ovpn/certs/${i}cert.pem
done
fix the “Client Status and -Control” overview of the N2N client ?
5 Likes
OK, I’ll give it a try this week.
BR
2 Likes
Does CU174 break existing OpenVPN c2n profiles that still rely on an old host certificate w/o key usage extention? I think I read somewhere that OpenVPN server 2.6.x will do so?
Or is it still safe for me to update w/o the need to re-create all client profiles?
The last openvpn server version change was to 2.5.8 in CU172.
What is being mentioned in the posts above is related to a commit to the perl code for the OpenVPN WUI page that will flag up how much time is left on client connection certificates.
The key usage extension was updated around 2019, maybe earlier. I have references to CU145 but also some back to CU115.
If it doesn’t get updated then eventually something will break. I don’t know if that will occur with version 2.6.0 or not.
Im asking since there are some removed/changed features in the changelog of 2.6.0 regarding cipher and certificate handling: openvpn/Changes.rst at master · OpenVPN/openvpn · GitHub
AFAIS one needs to set --compat-mode to be able to use old configurations and I don’t see any checkbox for that in IPFIre’s OpenVPN WUI. I can add that to the “server.conf.local”, of course.
Anyway, I’ll do some tests with a clone of my productive setup the next days to see if --compat-mode really helps. If not, we should add a warning to the release notes.
version 2.6.0 has some major changes and is therefore not being put into place yet.
Some significant changes are needed to the WUI due to trying to maintain older connection setups of users so that we try and avoid breaking existing setups.
If you have connection setups with older ciphers then when we have a modified WUI code it would be good if you will be able to test out the changes, as all of my setups have systems that I am unable to test old ciphers on.
If CU173 is working for you without --compat-mode then CU174 will also work.
I believe that will only be needed when version 2.6.0 is released in IPFire and that won’t happen till the WUI changes mentioned above have been worked out and tested.
3 Likes
Ah, okay, I thought I read somewhere that CU174 will come with 2.6.0. If that’s not the case, then we’re still safe to update.
Thanks for pointing out!
Hi all,
@chrisk1 , it might be great if you deliver your testing results (or also questions) in here → OpenVPN 2.6 Development version - #4 by ummeegge . There are also may some information according to your concerns.
Best,
Erik
I did some test today.
I have configured new connections between two IPFires
CU174 Development Build: master/11f4726b
Server side
Client side
after importing the Client Package file
-
The warning “Expired” appears
-
Only the .p12 file appears in the
/var/ipfire/ovpn/certs/folder
-
No reaction after clicking “Show file”
After use fix script
-
Warning disappears
-
An additional .pem file appears in the /var/ipfire/ovpn/certs/ folder
-
After clicking “Show file”
Best
1 Like