Here is the reply from Vimexx.
The first part is a response to me complaining about not getting a timely response.
There is a possibility that the requests are failing because the remote server is configured to accept only IPv6 traffic. We do not support IPv6, hence why the connectivity issue might occur.
First of all, this issue is so complicated that it usually takes me at least 15 minutes before I can even start a response.
In addition, I am almost constantly busy/needed to help colleagues.
That this ticket is more complicated, and requires more time & attention is of course no problem, but unfortunately this means that I can't handle it "just in between".
As a result, an answer unfortunately had to wait a while, so that you can at least get a complete and substantively correct answer from me.
Concerning the whitelisting I can be brief; no. There is no whitelisting, nor can there be one.
A whitelisting gives an IP address free reign, and is therefore a huge security risk.
In addition, whitelisting will not help against a non-resolving DNS.
You stated the following in an earlier post:
:~$ curl -I -X GET "https://download.regularlabs.com/updates.xml?e=extensionmanager&type=.xml"
curl: (6) Couldn't resolve host 'download.regularlabs.com'
However, this is not a problem the other way around:
[root@vps0216 ~]# curl -sIL "gtxm1232.siteground.biz"
HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 25 Jul 2023 14:55:40 GMT
Content-Type: text/html
Content Length: 162
Connection: keep alive
Location: https://gtxm1232.siteground.biz/
X-Default-Vhost: 1
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 25 Jul 2023 14:55:41 GMT
Content-Type: text/html
Content Length: 1371
Last-Modified: Tue, 18 Jul 2023 13:15:50 GMT
Connection: keep alive
Vary: Accept-Encoding
Tag: "64b69086-55b"
X-Default-Vhost: 1
Accept ranges: bytes
This also indicates that nothing should get in the way of the connection.
Could you ask SiteGround to run the cURL like this:
curl -4 -sIL -X GET "https://download.regularlabs.com/updates.xml?e=extensionmanager&type=.xml"
And additionally do the following cURL, to confirm that the problem is with the DNS:
curl -4 -skIL -X GET "185.220.175.129"
This should both work just fine, but probably only the bottom one will work, because there's a problem resolving the DNS.
As for only accepting IPv6 traffic on our end, this is simply not true.
Our servers support both IPv4 and IPv6 traffic.
We would like to receive the output of the curl commands above, and hope to be able to trace them.
If the cURL to the IP address also causes problems, we can try to (temporarily) disable the entire firewall.
If the problem is in the firewall it will take a lot of research on our end before we can fix it as it involves multiple IP's, but that should also be fixable 🙂