Hello,
I am a bit lost on this one.
I have suitecrm install on my own server ( (unbuntu 24.04). It is accessible from anywhere in the world, including my local network, using its dedicated domain name.
However when I am connected the server network with my providers VPN (IPsec/IKEv2 (strongswan)) , I have a NS-ERROR-CONNECTION-REFUSED in my browser (firefox) network.
I can ping the server no problem. Firewall is disabled.
Subnetworks of local, server, and VPN are different.
I did not find anything relevant in the Apache logs, neither the Suite CRM logs.
Any help woul be welbomed
Check what IP your SuiteCRM hostname resolves to over VPN
nslookup your.domain.tld
Confirm Apache is listening on 0.0.0.0 (all interfaces) and not bound to a specific address
sudo ss -tlnp | grep ‘:80|:443’
Try
sudo systemctl reload apache2
Check if ufw is off and empty
sudo ufw status
Check site URL
‘site_url’ => ‘http://example.com/suitecrm’,
1 Like
Hello,
Thank you for your help.
At the end of the day, my VPN does not loopback.
I had to create new hosts in etc/hosts/ on the user computer pointing the domain name to the local address.
With the help of an AI (because I am a noob), I created a deamon that checks if the VPN is active, and if so it adds the host, if not it removes it.
hi @MaitreCake
It sounds like you’ve hit the nail on the head. To answer your question: Yes, you have successfully identified and resolved the core issue, which was a classic DNS/Routing loopback conflict (often referred to as a lack of Hairpin NAT support on the VPN).
When the VPN is active, your computer tries to reach the SuiteCRM domain via the tunnel, but the tunnel doesn’t know how to ‘loop back’ to your local server IP. Your solution, using a daemon to automate entries in your /etc/hosts file is a very creative way to force Split-DNS behavior on a single machine.
A Quick Tip for the Future
While your script works great for your current setup, keep in mind:
-
IP Changes: If your server’s local IP ever changes, you’ll need to update that script.
-
Device Limits: This fix only works on the computer running the daemon. If you try to access SuiteCRM from a phone or tablet on the same VPN, you’ll likely see the error again.
If you ever want a more ‘permanent’ network-wide fix, the standard approach is to configure Split-Horizon DNS on your local router or DNS server. This tells any device on your network that yourdomain.com = [Local IP], while the rest of the world still sees your public IP.
Great job getting that automated, that’s a solid win for a self-described ‘noob’!"