security - client IP behind reverse proxy

[TobiasF]

Hello,

I am running my 3CX system behind a firewall (OPNsense) with nginx as reverse proxy for the 3CX webclient on port 443. This gives me additional security options as well an easy way to use Letsencrypt certificates.

The issue is that 3CX now does not recognize the real IP of the client and only my proxy IP is shown. By this am not able to use the security function of 3CX to restrict access to the webclient to internal IP only. The proxy IP is internal. Also editing the exception list in 3CX is not possible.

Forwarding header X-Forward-For or X-Real-IP by proxy also did not help. 3CX only sees the proxy IP and not the real client IP.

Any idea?

 

[BrenttG]

This is not a malfunction, this is due to what you have done, and 3CX does not support reverse proxying in this manner. And the fact you have set it up this way is ill advised. Not to mention without a doubt 3CX Support will directly tell you this is not supportable.

Not to mention, your reverse proxy will not protect the 3CX Server any better from injection based attacks than it already is, and if you begin implementing strict filtering of the web traffic, you are in for quite a suprise(errors).

If you have done all this just so you can use your own FQDN and not have to mess with SSL/TLS certificate management, the amount of headache you will face down the road with this setup is likely to outweigh the gain.

3CX is not a website, its not wordpress, joomla, etc.... Its much more complex, and while there are ways to make what your trying to do "technically" work most of the way, they are WAY outside of what 3CX considers supported, and when it breaks down, blows its top, etc, they will not be there to help you do brain surgery on it to fix it due to breakdowns your third party changes caused.

 

[cobaltit]

Very well written.. Sort version is follow the KISS principle

 

[TobiasF]

Thank you for the fast answer.

My key question is answered: 3CX system cannot do. So, I do not need to search any longer. Thank you.

(But still I feel a little bit like a young boy that came home with dirty clothes and got yelled on by his mom.)

I am a home user and I want “squeeze in” a pbx system in my infrastructure rather than building an infrastructure around a pbx system. I checked several pbx system: 3CX, FreePBX, Issabel, VitalPBX, Kamalio. With 3CX in combination with the free license I found a technical great system that does more than I need. It was quite easy to install and to set-up even without having deep technical knowledge. The Android app and the Apple and Google push service was what finally made my decision.

The reasons why I tried it this way with reverse proxy are:

• My fear having limitations by not using standard port 443 when trying to connect from outside by PC or by mobile app. e. g. from hotel WLAN. (Only fear, no prove for it)
• I only have a single IP. Port 80 and 443 is already used by my firewall/router and by my reverse proxy for other services.
• Letsencrypt already is running on my router. This was the easiest way. But getting certbot run (I am using Debian ISO) is not difficult too. But I guess – not supported by 3CX as well.

Your explanation helped me a lot even I believe that there is not so much rocket science in that cannot be handled by a reverse proxy. Websocket is the only point I discovered that requires special care and not to forget the real IP from my original post.

 

[JohnS_3CX]

Hi Tobias,

1. on this point, they could be blocking any port including 5090 which runs the 3CX tunnel, so 443 would be the least of your worries (you would only get presence and provisioning on 443 but no calls).

2. Not a problem at all if you use other ports such as our default 5001

3. We run our own LE certs, and update them automatically for you - nothing needs to be done on your end.

You sound like a guy who can figure things out, so just setup a VPN to connect home from anywhere, and you can bypass hotels policies etc. I imagine they would not opt to filter VPN connections since this would make many of their business customers quite unhappy for not being able to connect to their corporate network (again not that it would happen, but to address the fear/concern)

 

[TobiasF]

Thank's for all the explanation and recommendations.
It is clear to me now how the system is designed and supposed to work. I will reconsider my idea.

Yes, VPN is a solution for my concern reading non standard port 443. And VPN I already have set-up. But as under the hood of 3CX (debian ISO) is running nginx it also was not difficult to add "real_ip_header" in nginx.conf.

 

[JohnS_3CX]

Generally we will recommend to keep the system config as per our original design, since there are many things that are interdependent, and often it will not be worth the hassle or time spent troubleshooting if the change you want to make can be solved via other means.