General help

Switch on Debugging in Moodle. Check your web server error log. Hope you find something. It'll probably get tricky after that!

I am having the same problem. Have you found a solution yet? I would really appreciate your feedback

 Thanks.

Just 2 cents ... but something to investigate before jumping to conclusions that the issue is at one end ... the end point/destination point ... which, in this case is the Moodle.

Networking comes before Application.

A user using a device on the inside of a private network pulls a private IP address from the scope of available DHCP IP's for the private LAN/WAN.  So on the inside of your private LAN/WAN, what IP address are devices/workstations etc. pulling?   A 10.x.x.x?  A 172.16.? A 192.168.x.x?

That connection to the private LAN/WAN probably granted greater access to resources internal to the LAN/WAN but still under filtering/other network restrictions when inside the private network.

A user using a device on the  outside of the private network has to come in via the 'front door' to the private network - exception but still similar ... a VPN connection.  'Front door' meaning a gateway ... a public IP address from the range of static IP addresses assigned to the entity.

For a Moodle server to be fully functional both inside and out, it has to use a the same fully qualified domain name for public internet .... example ... real server that does host Moodles.

sos.tcea.org on the inside of the private network has a static IP address from 192.168.x.x block.  A Moodle hosted on that server has in it's config.php file sos.tcea.org/somemoodle/

To the outside world sos.tcea.org is a single IP address and it's FQDN in outside DNS resolves to a (this is not accurate) 208.xxx.xx.xxx IP address.

Both inside an outside, however, the FQDN is still sos.tcea.org

Now add to that filtering ... and Web Application firewalls ... those things hidden to users attempting to access - but known to the folks who run the networks.

So in trouble shooting such an issue one has to follow the path packets take while both inside and outside the LAN/WAN.   Stuff you can see ... and stuff you can't ... that's why the networking folks need to be involved.

Apologize if you know all that ... but still true ... follow the path.

Pings, Traceroutes, and Nmap scans from both inside and outside might be required to resolve.  Been my experience that for the most part, it wasn't a Moodle issue but in the paths between device attempting to access and destination .. the Moodle.  Can't consider just the end points cause that's not how packets route/go - point A to point B direct. ;)

For example ... Stoneware setup for LAN/WAN would require a reverse proxy in Moodle ... which, BTW, company says can be done .... back when Moodle was 1.9.x maybe ... but might be impossible with 2.x or 3.x.

'spirit of sharing', Ken