Test IPFire CU174

Okay. It’s for monitoring. I will follow the theme closely as well. I’m interested in it :smiling_face:.

1 Like

It seems that in version 174 the problem with high CPU and memory load by openvpn-authenticator is solved

after stopped

after restarting

after reconnecting red0

That was already fixed in the release version of Core Update 173. The problem with the update.sh script in CU173 Testing was identified and fixed.

2 Likes

But the n2n connection process is still active after stopping OpenVPN Server

CU173

CU174 Development Build: master/11f4726b

and I can connect to hosts on the remote network

:thinking: Is it a bug or a feature? :wink: :wink: :smiley:

1 Like

That is different to openvpn-authenticator.

I am not familiar at all with n2n openvpn so don’t know if that is expected or not.

If n2n connections should also be stopped when openvpn is disabled then that sounds like a bug that should be raised.

Maybe some else familiar with n2n can comment on this.

1 Like

N2N uses a different instance (different port, different tun device, …) then the OpenVPN Server. To stop the N2N connection you can disable it in “Client Status and Control” by unchecking the hock of the corresponding connection → git.ipfire.org Git - ipfire-2.x.git/blob - html/cgi-bin/ovpnmain.cgi .

Best,

Erik

3 Likes

As Erik mentioned, uncheck the checkbox in your net to net connection line.

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 :unamused:.
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 :unamused:.
Let’s hope for help from other users.

Don’t give up :smiley:

wiki.ipfire.org - OpenVPN Configuration

wiki.ipfire.org - Append a network-to-network connection

wiki.ipfire.org - Net-to-Net as a TLS-server:

wiki.ipfire.org - Net-to-Net as a TLS-client:

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 :joy:.

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