Hestia Panel running slow on a local VM

I’m running HestiaCP on a local VM exposed to the internet with an OpenVPN tunnel that runs on an Amazon Lightsail instance. Since a couple of weeks ago, the Hestia Panel is running pretty much slower than before. I tried accessing the panel using the local IP and it still runs slow somehow.

Additionally, and I think this is also related to the same issue, the WordPress Dashboard hosted on the same local VM sheds cURL 28 errors (timeouts), stating that the issue might be related by either a firewall blocking outbound calls, an outdated version of PHP or a DNS problem. Timeouts occur generally when accessing the WordPress dashboard and every time I want to view the analytics in it.

I believe this can be related to a firewall issue that is blocking the outbound calls. This is only affecting the backend, the website performs quite well despite this wacky experiment.

Currently, I’m redirecting all the traffic from the Lightsail instance to my local VM. TCP: 53, 80, 443, 3306, 8083 and UDP: 53. This is the way I do it:

sudo iptables -P FORWARD DROP
sudo iptables -A FORWARD -i eth0 -o tun0 -p tcp --syn --dport 53 -m conntrack --ctstate NEW -j ACCEPT

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 53 -j DNAT --to-destination IPnumber
sudo iptables -t nat -A POSTROUTING -o tun0 -p tcp --dport 53 -d IPnumber -j SNAT --to-source Ipnumber

I tried to restore the local VM to a previous snapshot and the issue still occurs. I know this can be happening for many reasons, any hints that could help me sort out what can be occurring would be really appreciated.

I suggest to look into the sources the Dashboard tries to access. maybe there is some plugin running that wants to load in some external asset from it’s vendors server or the like. and if it cannot reach that host/IP properly (due to a dns issue for instance) this could block the page/dashboard from rendering…

if the Hestia dashboard also is slow this suggests a similar issue but indeed makes it a bit more strange, as you would need the rather same try to access something external.

maybe your local server itself has issue with dns resolution? why would you send port 53 through the tunnel at all, I don’t think that’s a good idea…

Thanks falzo. I’ve been running some tests with the console and I get the following message either by entering the Wordpress dashboard or the MonsterInsights Analytics:
?v=2.0:16 WebSocket connection to ‘wss://public-api.wordpress.com/pinghub/wpcom/me/newest-note-data’ failed:
There are some localhost requests to port 3000/1, I tried opening them in HestiaCP’s firewall and the Lightsail instance as well and the issue still occurs.

By the way, this is only hapenning with this experiment, I have no issues so far running VPS natively on a Lightsail instance itself.

if that’s a request to localhost, then more likely a service is expected to listen there. I don’t think that’s related to the wss request as web sockets afaik still are 80/443 in that case.

my money is still on it being a dns issue. have you tried not pushing port 53 through the tunnel but instead having your local instance use your normal upstream dns?

Probably it is. I tried removing the iptables rule for Port 53 and unfortunately the issue still occurred. After that, I lost access to the HestiaCP panel itself (hostname.domain.tld) so I had to revert the changes.

Curiously, a couple of weeks ago everything was working fine. No timeouts, nor slow speeds in the panel. I’ve heard somewhere that this could also be due to a wrong SSL certificate. Everything seems to be fine in that regard though.

I had hestia running in a DMZ with tunneling 80/443 through tinc to a public IP and can’t remember any bigger issues. I for sure did not forward DNS but made sure dns resolution still worked within the DMZ (as it should anyway).
maybe try pinging e.g. that public-api.wordpress.com domain from your local machine to see if dns resolution works, does that find an IP to the name and give a proper echo?

Thanks man. The local instance pings fine to public-api.wordpress.com (192.0.78.22). As for the DNS resolution within the DMZ (I assume it’s the local Hestia installation), I’m not sure where to check that exactly. There, I have configured two IP addresses. The local network IP (enp0s3) and the IP given by the VPN, which translates into the NAT IP of the Lightsail instance (public IP).

It is weird since the wordpress blog performs fine, the only issue is with the backend plugins and HestiaCP panel performance.

Settings > Configure > Basic Options > Hostname

I did solve my problem with change hostname with working one. Maybe this can solve someones problem.