executive wrote:

wurdeman wrote:

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.1 <<>> piwigo.org
;; global options: +cmd
;; Got answer:

Doesn't this mean piwigo.org replied to your server?

That only means his DNS resolver on internal 10.0.80.11 knows an IP for it, nothing else.

Thanks for the code....

root@server6 [~]# curl -I -v https://piwigo.org
* About to connect() to piwigo.org port 443 (#0)
*   Trying 87.98.147.22... Connection refused
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to hostexit

Gentlemen, I am an IT specialist / software developer by trade. I ran into this problem and came to the forums to see what others said. I was able to resolve my problem and wanted to post about it because I think this could help others who said they had better luck after switching hosts.

My situations symptoms:
Windows Computers could connect to Piwigo.org
Linux servers COULD NOT connect to Piwigo.org
Current Piwigo version installed to Ubuntu 18.04 Apache 2.4 PHP7.4-FPM*

On the linux machine I performed a dig and could resolve the server. I could not curl to get the download, nor could I even curl the main site, or wget the main site piwigo.org.  Other sites did work.  There was nothing wrong with dns resolution.  All of my servers are headless so I installed a linux workstation and tried to connect to Piwigo via google chrome web browser. I was able to make that connection, but still unable to curl and wget from command line. 

I still have no idea what the web browser is doing to bypass the cause of the problem but the web browsers were able to access the site when they were not supposed to be able to by my router configuration. The root cause was in my security gateway. At home I run a full Ubiquiti Unifi setup similar to my office. There is a setting for GeoIP filtering to allow or block traffic by country.  I allowed only US traffic when it was not working. As soon as I disabled the filter the plugins and updates worked from the site, and I could curl and wget from the command line as well. 

I cross referenced the IP from piwigo.org in whois to see who it was assigned to. It was RIPE out of Netherlands as I suspected, but that is not necessarily the country assigned to the address.  Cross referenced the geolocalization for this ip assignment https://www.geodatatool.com/en/?IP=51.38.237.64 and found this IP is assigned to France.  Added France to the allowed list in the firewall and everything works. 

Bottom line -- it was a firewalling issue on the client end blocking the connection to France. 

* with php7.4 most things work but there are some errors. Particularly with mysql and the implode function which no longer supports reversed parameters.  I will create a separate issue on this.  https://www.php.net/manual/en/migration … ecated.php Implode with historical parameter order Passing parameters to implode() in reverse order is deprecated, use implode($glue, $parts) instead of implode($parts, $glue).

If I had only a Piwigo server running in my data closet at home then I would open it wide. With my dev servers for work its a completely different story. 

The takeaway I was shooting for was that even though many factors indicated an isolated problem with one device inside my network it was in fact a broader issue in the firewall blocking the traffic. It's still a mystery to me how google chrome was getting around the firewall. Its as if they are proxying the web traffic between the web browser and piwigo.org server.