FreePBX web interface behind Cloudflare CDN?


#1

Hi, I’d like to provide UCP to some of my users but wouldn’t like to expose the server IP address.

Is it going to work well if I provide them with a domain behind Cloudflare for UCP purposes, while I access the admin panel and extensions (port 5060 and so on) directly with the server IP to work around the CDN?

Or if you guys have any other suggestions to accomplish the same thing.

Thanks!


(Itzik) #2

Did you ever implement this?


(Kevin Frost) #3

I’m currently looking into implementing this and will link to a topic w/ guide.


(Jared Busch) #4

Untested guess is that you don’t even need to use IP. Just use a second FQDN for the provisioning and registration.

Let https://prov.domain.com point to your server and not have the orange cloud in CloudFlare

Let https://pbx.domain.com be a CNAME on CloudFlare and point to prov.domain.com and have the orange cloud.

Tell CloudFlare to use Full but not strict HTTPS.


(Kevin Frost) #5

I’m testing this right now in real-time and there are some bugs with her. First, when I use proxy (orange cloud) on my subdomain ipcom-1, all traffic gets blocked on my sip protocol. all endpoints drop.


(Kevin Frost) #6

The firewall rules don’t work for SIP, only http/s… Would a CF automated worker be helpful?


#7

“The firewall rules don’t work for SIP, only http/s”

huh?


(Kevin Frost) #8

In cloudflare you have to set up firewall rules, srv records and etc. I’m currently troubleshooting connectivity between my endpoints and the pbx because when you use CF you have to use their nameservers.


#9

And in my experience with CF, correct SRV records will help prevent arbitrary attempts against you IP, on your asterisk end reject all sip connections to your IP address. That way only SIP requests against your domain name will return anything useful (and of course your endpoints will be set to contact to your name not your address). (It works well for me)


(Kevin Frost) #10

So it seems the proxy is on and the SRV seems to be correct, however in the freepbx logs i see this:

[2020-02-10 15:37:44] WARNING[10955] chan_sip.c: sip_xmit of 0x7f00e40f2b50 (len 610) to 107.xxx.xxx.xxx:31488 returned -2: Success
[2020-02-10 15:37:44] ERROR[10955] chan_sip.c: Serious Network Trouble; __sip_xmit returns error for pkt data
[2020-02-10 15:37:44] WARNING[10955] chan_sip.c: sip_xmit of 0x7f00e4009020 (len 610) to 68.xxx.xxx.xxx:64438 returned -2: Success
[2020-02-10 15:37:44] ERROR[10955] chan_sip.c: Serious Network Trouble; __sip_xmit returns error for pkt data

Registrations are failing. I assume the SRV is correct since the PBX can ‘see’ the traffic hitting it. The PBX transport is set to TLS. Thoughts?

EDIT: Mind you, everything worked before. Queues, video calling via srtp, etc… Had to reroute the GUI HTTPS traffic to port 2053 for CF to allow it.


#11

SRV lookups need to be enabled on whatever channel you are using. PJSIP works well, chan_sip can be a little squirrely but start with setting

srvlookup=yes


(Kevin Frost) #12

I’m using chan_sip. pjsip breaks some things on my end and in my experience plays with sipstation better.


#13

hehe, there you go, so far for me also chan_sip works fine for trunking. Any number of folks will scream at you that it is “depreciated/deprecated” and will imminently stop working, but so is PHP 5.6, they will likely both be there for years though :wink:

Either way, you need to inform asterisk that you are expecting SRV lookups.


(Kevin Frost) #14

This is what the SRV looks like in CF:

Is this correct?


#15

Now try looking at sngrep for your servers resonse to the call. Did you enable SRV in asterisk yet?


(Kevin Frost) #16

Yes. May have to reload. I’m using 12.7.6-1910-1.sng7 and set Enable SRV Lookup to Yes in chan_sip settings plus added srvlookup=yes under Other SIP Settings.


#17

sngrep is a nice and easy way to parse what the two parties think of each other, try it.


(Kevin Frost) #18

Getting it from github as we speak


#19

You probably have it already.


(Kevin Frost) #20

Yeah i do. sngrep isn’t seeing the endpoints trying to register but they’re hitting as shown in the logs… Suggestions?