It always happens the same I deleted the old client and created a new one. Imported this back into Debian in the VPN settings → As soon as I click connect, the server is offline.
So you are trying to connect from the debian system to the IPFire OpenVPN server and the act of trying to connect is causing the server to shutdown!
That is very strange.
Is there anything in the vm IPFire logs to show why the server shutdown?
What is showing in the debian logs for when the client tries to connect?
The error message with the existing client must have been different.
I’m sorry!
@ummeegge do you have any ideas of what might be causing @dyle the problems he is experiencing.
I have never experienced a situation where the act of trying to connect from a client causes the IPFire server to stop running and no messages found in the logs to explain why and the server won’t start again until the IPFire machine has been rebooted.
I have run out of ideas.
In “OpenVPN Roadwarrior connection log” is nothing like always or which “IPFire protocols” do you mean?
I have to search in debian first.
I took this Debian VM because it has the same SSL version as fire (1.1.1.)
Yes, that was my question.
Will wait to see if you find anything in there.
Similar openssl version is a good idea as it removes any issue about the differences from 1.1.1x to 3.x
I have requested @ummeegge for any input as he is very knowledgeable on OpenVPN and has been responsible for developing a lot if not most of the code used in IPFire.
In Debian I only see the message from the network manager “Failed to activate the network connection” Which is normal when the server is stopped.?
The crashing of the VPN server (IPFIRE) only happens with the first connection attempt of the new client. After that, no connection is established, but the server continues to run.
Unfortunately not now the server is offline again after trying to connect again. =((
Hi all,
puhhh there´s a lot of different problems to read through. One thing which jumps into the eyes are here → VPN RoadWarrior Connection Fritzbox --> IPFIRE --> Ipfire (red) --> Ipfire (blue) - #15 by dyle . If you try to access OpenVPN from WAN you can not use a privat IP address range also, “:1194” is not the correct place to define the OpenVPN port therefor you should use “Destination port:” (this should throw errors in the WUI) . If your IPFire is behind a router (Fritzbox) you need nevertheless to add your WAN address (DDNS or fixed IP) since your client needs to find the address otherwise there are no connection and no logs . Your DNAT from Fritzbox should be OK then.
The OpenVPN connection log → VPN RoadWarrior Connection Fritzbox --> IPFIRE --> Ipfire (red) --> Ipfire (blue) - #29 by dyle will only show active connections.
If your OpenVPN server does not want to start take also a look into /var/log/httpd/error_log but if you have wrong parameters in the WUI it won´t start but should throw in mostly cases an error message in the OpenVPN WUI.
Some things for the first to not overload the answer.
Best,
Erik
P.S.: If you have a block FORWARD FW, you will need to set rules for your clients which should be accessible
5 Likes
Hello,
In the FritzBox I use “xxxxx.myfritz.net” for VPN
Should I also register them with the IPFIRE?
I want to try it again with a new installation in which I don’t import my backup to see if it works.
In my test IPFIRE installation I had also used 174 and then imported the backup from my production system and got the same error.
Here is a screenshot of the rule I created for the VPN client.
Would this be correct?
Hello,
no this won´t be correct. If you want a connection to OpenVPN on IPFire you will need a public address if you have a static IP you can use it if not use a DDNS address which should be entered under “Local VPN Hostname/IP” . Your Fbox needs to make a port forwarding DNAT to IPFire OpenVPN nothing else.
I would encourage you to read the statement above again (spend yourself a little more time with it) and figure out what it means and do not try too much other stuff around it. If it makes no sense for you, ask specific to the already written. If this is all too far, please check the documentation → wiki.ipfire.org - Global settings and go trough the points which are unclear for you.
The OpenVPN server must run and the configuration should be OK otherwise all other parts (different client checks) makes no sense.
Best,
Erik
P.S.: Also, if you want to push connections to blue0 please read in here → wiki.ipfire.org - Client configuration too.
3 Likes
Good day,
Just for understanding:
The “OpenVPN Subnet” and the “Static IP Address Pools”
must be on the same network, right?
Or do I have to enter this static pool manually on the client?
nice week
Hello,
if you have chosen a “Static IP address pool” your OpenVPN subnet is part of this address pool. “Static” means, the OpenVPN subnet won´t change for this client(s) so it is reliable for firewall rules since you can assign a pool of addresses (or single addresses /32) to specific clients via CCD (client-config-directory)–> wiki.ipfire.org - Static IP address pools .
If you do not choose a “Static IP address pool” you will get a dynamic (automatic) address assignment from OpenVPN which will be then your OpenVPN subnet.
Best,
Erik
P.S.: @dyle if you have meanwhile success with the headline question of your topic, please write it here if and if not, why. According to the community rules, prevent other questions and open up a new topic for them this might be good also for others.
2 Likes
Hello Erik,
Thanks for your answer!
I have the problem that the clients can connect but are not connected, “Connection status and control” is green (connected)
and at “OpenVPN server status is STOPPED”
It may be that I used the static pool but didn’t give the client a fixed IP address.
I will test it further next week with dynamic address range.
In any case, the clients can connect, which is all the more surprising since the VPN server is not running.
nice week
After a reboot it is now running very well.
Except for problems when the client sits behind a proxy server.
I’m opening a new thread for this.
Thanks again =))
2 Likes