PP Christian
Staff member
We are replacing a few servers because of the many blocked ips, Amsterdam has already been replaced, the 4 that are now offline will also be replaced as soon as the hosters have delivered them complete with ips.
Serverstats - Current information about the servers
- Thread starter PP Christian
- Start date
hallowelt2
Freshly Joined Member
Stupid question from someone who doesn't maintain servers. Can't you use the old servers and just change the IPs? As far as I know IPs aren't branded in the Server hardware (unlike your Windows license in branded into your Laptop)? Or is is also some Hardware-Upgrade?
edit: Or is the hoster the problem and says you also need to change the server? But nice to see many servers are back again, inclusive Los Angeles which I currently don't use but was offline for a long time. And also Hongkong.
edit: Or is the hoster the problem and says you also need to change the server? But nice to see many servers are back again, inclusive Los Angeles which I currently don't use but was offline for a long time. And also Hongkong.
PP Christian
Staff member
As far as I am correctly informed, new hardware is also being used.
Honk
Member
I'm wondering what the serverstats site is telling us. According to this site, Moscow and Paris are up and running, but that's not true. In fact, all three servers are not working properly, as my captures show.
Moscow1: https://pomf2.lain.la/f/cztwnmf4.mp4
Moscow2: https://pomf2.lain.la/f/tafj5p9x.mp4
Paris: https://pomf2.lain.la/f/v3p18pc.mp4
That being said, I recommend that you change the way you test the servers listed on this page. Maybe the servers listed here work fine with SSH or other features, but that's not the case for VPN, at least.
Even if the VPN login is successful, it doesn't mean that it works the way it should, as you can see with the download test. So please consider implementing a download test as well, and if it is successful, this server can be considered as working properly, otherwise the stats page is telling shit.
I'd also like to add that the Moscow issue has been going on for months and the Paris issue for weeks.
Why are you not able to fix it within days? If the server doesn't work well, reinstall it from scratch. If it's not a server configuration issue, move to another server or datacenter. Downtime that long is unacceptable, and it's something that pisses off customers, and rightfully so.
Also, please stop telling us that guy X is sick or on vacation as the reason things aren't getting fixed, I don't care who finally gets it done. I made my payment to this company and therefore this company is responsible for keeping things up and running.
Moscow1: https://pomf2.lain.la/f/cztwnmf4.mp4
Moscow2: https://pomf2.lain.la/f/tafj5p9x.mp4
Paris: https://pomf2.lain.la/f/v3p18pc.mp4
That being said, I recommend that you change the way you test the servers listed on this page. Maybe the servers listed here work fine with SSH or other features, but that's not the case for VPN, at least.
Even if the VPN login is successful, it doesn't mean that it works the way it should, as you can see with the download test. So please consider implementing a download test as well, and if it is successful, this server can be considered as working properly, otherwise the stats page is telling shit.
I'd also like to add that the Moscow issue has been going on for months and the Paris issue for weeks.
Why are you not able to fix it within days? If the server doesn't work well, reinstall it from scratch. If it's not a server configuration issue, move to another server or datacenter. Downtime that long is unacceptable, and it's something that pisses off customers, and rightfully so.
Also, please stop telling us that guy X is sick or on vacation as the reason things aren't getting fixed, I don't care who finally gets it done. I made my payment to this company and therefore this company is responsible for keeping things up and running.
Honk
Member
And the shit goes on ...
AUTH: Received control message: AUTH_FAILED
AUTH: Received control message: AUTH_FAILED
Code:
# openvpn --config Nuremberg2.conf --script-security 2 --route remote_host --persist-tun --up updown.sh --down updown.sh --route-noexec --setenv hopid 2 --setenv prevgw 10.4.99.1
2024-11-20 18:16:11 Multiple --up scripts defined. The previously configured script is overridden.
2024-11-20 18:16:11 Multiple --down scripts defined. The previously configured script is overridden.
2024-11-20 18:16:11 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2024-11-20 18:16:11 WARNING: file 'client.key' is group or others accessible
2024-11-20 18:16:11 OpenVPN 2.5.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jun 27 2024
2024-11-20 18:16:11 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2024-11-20 18:16:11 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2024-11-20 18:16:11 TCP/UDP: Preserving recently used remote address: [AF_INET]80.255.10.194:4433
2024-11-20 18:16:11 UDP link local: (not bound)
2024-11-20 18:16:11 UDP link remote: [AF_INET]80.255.10.194:4433
2024-11-20 18:16:11 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1617', remote='link-mtu 1633'
2024-11-20 18:16:11 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
2024-11-20 18:16:11 [Server_nuremberg.perfect-privacy.com] Peer Connection Initiated with [AF_INET]80.255.10.194:4433
2024-11-20 18:16:13 AUTH: Received control message: AUTH_FAILED
2024-11-20 18:16:13 SIGTERM[soft,auth-failure] received, process exiting
root@comp:/home/user/vpn/PP/udp#Honk
Member
Now I'm having issues with London1 VPN, it says certificate verify failed, while London2 works properly.
Code:
2024-11-25 17:07:30 VERIFY ERROR: depth=0, error=certificate has expired: C=CH, ST=Zug, O=Perfect Privacy, CN=Server_london.perfect-privacy.com, emailAddress=admin@perfect-privacy.com, serial=14998562583678579446
2024-11-25 17:07:30 OpenSSL: error:0A000086:SSL routines::certificate verify failed
2024-11-25 17:07:30 TLS_ERROR: BIO read tls_read_plaintext error
2024-11-25 17:07:30 TLS Error: TLS object -> incoming plaintext read error
2024-11-25 17:07:30 TLS Error: TLS handshake failed
2024-11-25 17:07:30 SIGUSR1[soft,tls-error] received, process restarting
2024-11-25 17:07:35 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2024-11-25 17:07:35 TCP/UDP: Preserving recently used remote address: [AF_INET]82.199.130.34:443
2024-11-25 17:07:35 TCP/UDP: Preserving recently used remote address: [AF_INET]82.199.130.34:443
2024-11-25 17:07:35 UDP link local: (not bound)
2024-11-25 17:07:35 UDP link remote: [AF_INET]82.199.130.34:443
^C2024-11-25 17:07:35 event_wait : Interrupted system call (code=4)
2024-11-25 17:07:35 SIGINT[hard,] received, process exiting
PP Christian
Staff member
I can repeat it again here. We are of course working on getting the servers in order. We are not as well staffed as the popular providers, but we offer the highest standards in terms of security. Better a server offline than possibly insecure connections. We have proven this impressively in more than 15 years. Nevertheless, we can understand the annoyance when individual servers fail. That annoys us too, of course. Sometimes it takes a little longer for the admins in the data centres to process our tickets properly. If they make mistakes there, the servers don't work according to our requirements. And in case of doubt, that's better than if the security is patchy, to put it simply.
Thank you for your understanding.
hallowelt2
Freshly Joined Member
Don't know if it helps, but some time ago in the german forum someone said new staff also has to be trustworthy. As I stated in the german forum, the police/3 letter agencies/... are unbelievable good in finding people who can be bought with money or put their own spies in there. So you can't just hire anyone new or post job vacancies.
Also as PP stated, they have real servers at the location, not just exit-points (or whatever it is called, apparently some other provicer do it?). So it is a difference if you have real servers in the stated city and have to wait until the data center react or if it is some exit point and all servers are locatec in country X what would be a big security breach; and if the connection to country X is severed, nothing works. With real servers in the country you have more security and better connection.
And we're here for the security and privacy.
Also as PP stated, they have real servers at the location, not just exit-points (or whatever it is called, apparently some other provicer do it?). So it is a difference if you have real servers in the stated city and have to wait until the data center react or if it is some exit point and all servers are locatec in country X what would be a big security breach; and if the connection to country X is severed, nothing works. With real servers in the country you have more security and better connection.
And we're here for the security and privacy.
PP Christian
Staff member
Frankfurt, Erfurt and Warsaw should be back soon. We've swapped hardware and partly switched from M247 to other data centres.
By the way: We will be saying goodbye to Hamburg completely because the routing is/was so bad that we are now replacing it with Düsseldorf.
The fact that servers go down or are cancelled is a completely normal process and in the following screenshot you can also see that the grass is not greener elsewhere ;-)
View attachment 1732800688174.png
By the way: We will be saying goodbye to Hamburg completely because the routing is/was so bad that we are now replacing it with Düsseldorf.
The fact that servers go down or are cancelled is a completely normal process and in the following screenshot you can also see that the grass is not greener elsewhere ;-)
View attachment 1732800688174.png
hallowelt2
Freshly Joined Member
Let's just say the competitor has the same problems. Maybe they forward you to another server and don't tell you so you think they don't have problems. Maybe they have only exit-points in other countries so you have a wrong security. Whos knows. But the competitor also has ->maintenance<-. Otherwise they have a very big problem.
Honk
Member
What does the server status page actually say? It seems to be fiction!
Code:
# amsterdam2u
2024-11-30 15:49:41 Multiple --up scripts defined. The previously configured script is overridden.
2024-11-30 15:49:41 Multiple --down scripts defined. The previously configured script is overridden.
2024-11-30 15:49:41 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2024-11-30 15:49:41 WARNING: file 'client.key' is group or others accessible
2024-11-30 15:49:41 OpenVPN 2.5.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jun 27 2024
2024-11-30 15:49:41 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2024-11-30 15:49:41 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2024-11-30 15:49:41 TCP/UDP: Preserving recently used remote address: [AF_INET]212.7.209.236:44
2024-11-30 15:49:41 UDP link local: (not bound)
2024-11-30 15:49:41 UDP link remote: [AF_INET]212.7.209.236:44
^C2024-11-30 15:51:36 event_wait : Interrupted system call (code=4)
2024-11-30 15:51:36 SIGINT[hard,] received, process exiting
Code:
root@comp:~# amsterdam3u
2024-11-30 15:46:59 Multiple --up scripts defined. The previously configured script is overridden.
2024-11-30 15:46:59 Multiple --down scripts defined. The previously configured script is overridden.
2024-11-30 15:46:59 --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2024-11-30 15:46:59 WARNING: file 'client.key' is group or others accessible
2024-11-30 15:46:59 OpenVPN 2.5.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jun 27 2024
2024-11-30 15:46:59 library versions: OpenSSL 3.0.2 15 Mar 2022, LZO 2.10
2024-11-30 15:46:59 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2024-11-30 15:46:59 TCP/UDP: Preserving recently used remote address: [AF_INET]212.7.209.237:44
2024-11-30 15:46:59 UDP link local: (not bound)
2024-11-30 15:46:59 UDP link remote: [AF_INET]212.7.209.237:44
2024-11-30 15:48:59 [UNDEF] Inactivity timeout (--ping-restart), restarting
2024-11-30 15:48:59 SIGUSR1[soft,ping-restart] received, process restarting
2024-11-30 15:49:04 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2024-11-30 15:49:04 TCP/UDP: Preserving recently used remote address: [AF_INET]212.7.209.237:44
2024-11-30 15:49:04 TCP/UDP: Preserving recently used remote address: [AF_INET]212.7.209.237:44
2024-11-30 15:49:04 UDP link local: (not bound)
2024-11-30 15:49:04 UDP link remote: [AF_INET]212.7.209.237:44
^C2024-11-30 15:49:21 event_wait : Interrupted system call (code=4)
2024-11-30 15:49:21 SIGINT[hard,] received, process exitingPP Christian
Staff member
As you can see, some servers have come back. Most of the servers have been taken offline by the data centres due to ‘abuse’. Core Backbone, where we host the German servers, was particularly annoyed, so they all went down at once. Hardware is still being replaced on the servers that are not coming back immediately, so this may take a few days longer.
All we can do is ask for your patience and understanding. Of course, we are just as annoyed as you are. But that's the price you sometimes pay for a 100% No LoG VPN.
All we can do is ask for your patience and understanding. Of course, we are just as annoyed as you are. But that's the price you sometimes pay for a 100% No LoG VPN.