Suitecrm access - Weird one that has me stumped!

Hi guys this is driving me nuts… any help much appreciated!

In my installation I have suitecrm installed behind a secure reverse proxy (that terminates all SSL for the LAN servers). Essentially:

WAN/Internet <—SSL—>Gateway<–SSL–>Reverse Proxy<—No SSL—>Servers (inc. SuiteCRM)

So I installed suitecrm 8.7 on an on-prem in an LXC in a VE and users can reach it from the LAN and it’s working perfectly… The site_url config is set as IP address x.x.x.x - great so far!

I then pointed the nginx reverse proxy at the suitecrm server and all appears to be working properly…users can access it from the LAN - again brilliant!

I then opened another port in the firewall and directed the DDNS provider (as I’m testing at home, it was duck dns) at the reverse proxy… and at this point I hit some weird behaviour:

From inside LAN: SuiteCRM loads fine when accessed through the reverse proxy on the LAN
From internet/WAN: SuiteCRM can be reached, but partially loads to a blank page (I believe this is probably graphqL related)

Now I thought this could be down to a firewall rule, but there are no firewall rules that would appear to conflict either at the gateway or on the hypervisor VE.

Basically this works:
Local LAN client<–SSL–>Reverse Proxy<—No SSL—>SuiteCRM
But this fails to fully load:
WAN/Internet <—SSL—>Gateway<–SSL–>Reverse Proxy<—No SSL—>SuiteCRM

So any ideas here? All help very gratefully received!

  • Check the configuration of your Nginx reverse proxy. Ensure that you have the correct headers set up to forward the necessary information. Example,
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

  • Since the reverse proxy handles SSL, ensure that the X-Forwarded-Proto header is correctly set to https when accessing from the WAN

  • Check if you have any console errors.

  • Clear your browser cache and cookies

  • lastly, double check your firewall settings.

Thanks @rsp … yes I’ve been through all of the usual:

Nginx reverse proxy is configured and working properly or I would not be able to use it to access suitecrm from the lan successfully - I’ve also treble checked the server block, even increasing buffer sizes just in case.

Again headers are set correctly and if I use the xxx.duckdns.org domain name to access the reverse proxy from inside the LAN then the proxy deals with all the forwarding and suitecrm works as it should.

There are no errors in the apache2 error log. The access log shows a connection being established from the WAN (or LAN) but then if it’s from the WAN the connection proceeds no further and there is no following GET request to GraphQL in the logs. Yet there is nothing in the error logs.

From the nginx side a POST request to GraphQL is being made in the access log… but again nothing in the error log.

I’ve treble checked VE and gateway firewall rules… it’s all very odd!

My next step is going to be a fresh install if I can’t figure this out

Ok I eventually solved this after many many hours…

The clue was the lack of response to the post argument to graphql on the reverse proxy and I would have tracked this down sooner if I had a better knowledge of the modsecure WAF…

So for others - I made 1 big mistakes that led to this in my logic:

I had

I had assumed that this could not be the WAF on the reverse proxy because the reverse proxy was working and serving suitecrm properly from within the LAN and it was only from outside the LAN that issues arose. As the WAF would be inspecting all requests regardless (both inside and outside LAN), it could not possibly be it as it would also be blocking LAN side requests to suitecrm, right? …wrong!

Because of the way modsecurity WAF works in anomaly mode, the odd nature of the graphql post syntax was generating a high anomaly score using the core rulset even on the test setting, when added to a higher risk source location (wan) the request wasn’t triggering any particular rule fully, but was exceeding the overall anomaly threshold and shutting down the connection… But obviously only if the source location for the request was outside the LAN as from inside the LAN it was just under the threshold.

I usually start with very high thresholds for test purposes, so this is really a suprise and not something I’ve seen before. It’s with noting that this behaviour would happen regardless of whether you’re running modsecurity on a tested reverse proxy or directly on the suitecrm server. So the message for others is - modsecurity and suitecrm do not initially play well together because of the graphql implementation and you’ll need to start with a much lower test setting on modsecurity than you’re used to.

Anyway hope that helps some poor tech in the future struggling with the same issue…10hrs of my life wasted going round in circles! Could kick myself!

1 Like