DNS resolves wrong IP address in one country
Solution 1:
As MadHatter wrote, this is the end-users' ISP (Swisscom) re-routing your site through a filtering proxy. It is quite probably that all users subscribing to their Internet Guard service are actually proxied through there, not just your site.
They say that the filter is against malware, phishing and viruses, so it shouldn't be an issue of "classification", but one of security.
Your first step should thus be to check that the site has not been infected. PHP sites tend to be quite vulnerable (if someone finds a way to upload a .php file somewhere in the visible hierarchy, it can then be executed remotely to do anything they want). There are also many other ways to do harm (SQL injections, stored XSS...).
Your home page is not blocked, or at least not all the time, so either:
- only some of the pages are infected
- the infection only shows up a fraction of the time on user requests (a common strategy to fly under the radar)
- or there is something else on some pages that triggers a false positive
You can see the result yourself by pointing the website's address to the IP address of the proxy. You can do that by editing your /etc/hosts file (details vary based on platform) and adding a line:
195.186.210.161 elearning.affis.ch
You can then visit the site as one of those users, and see which pages are blocked or not.
Once you have a better feel of what pages are blocked or not, it might be easier to pinpoint the actual issue. Then fix it, and either it will suddenly go through right away, or you may have to report a false positive (there's a link for that at the bottom of the "blocked" page).
Note that trying to report a false positive before checking for infection would probably be counterproductive. Try very hard to find and fix the issue first.
Edit
Note that the version of Claroline you run (1.11.9) has multiple XSS vulnerabilities known since 2014:
Multiple cross-site scripting (XSS) vulnerabilities in Claroline 1.11.9 and earlier allow remote authenticated users to inject arbitrary web script or HTML via (1) the Search field in an inbox action to messaging/messagebox.php, (2) the "First name" field to auth/profile.php, or (3) the Speakers field in an rqAdd action to calendar/agenda.php
If the issue is indeed a stored XSS attack, take the latest dump of your database and check if it contains anything like a <script tag (don't forget to search case-insensitively).
Solution 2:
If you point a browser at the IP address returned, http://195.186.210.161/, you get Swisscom's "dangerous website blocked" message. My guess is that their "safe internet" content-blocking system works, at least in part, by lying in response to DNS requests, and that your website is falling foul of them, for some reason.
I understand that you asked them if they were blocking you, but in my experience even medium-sized ISPs' front-line tech support don't have the slightest idea what's going on out back. It's quite possible that the whole nanny system is outsourced (or done by a third-party commercial product) and that nobody at Swisscom has any idea which sites are blocked at any given time. Asking your student if (s)he has any kind of "nanny internet" settings on may be more productive.
At the end of the day, this may not be a problem you can solve, since you're not that ISP's customer, and they owe you nothing. Having the student's parent call their ISP support, complain loudly about wrong DNS resolution, and threaten to change ISP if it's not resolved, is likely to be the only thing that has any effect.
Edit: this thread suggests that Swisscom's site blocking engine can be a bit over-enthusiastic, and that it's not always easy to get any kind of positive resolution from them. It also suggests that this isn't an opt-in filter, but that it applies to all Swisscom customers whether they like it or not, so opting out of it may prove to be difficult.