I’m behind a pfsense gateway correctly set up to forward the correct ports to the freepbx server.
I have a dynamic dyndns hostname correctly updated by pfsense.
I have a trunk with my VOIP provider (Vodafone Italy) which correctly connects.
If I set the external IP in SIP Settings address with my dynamic hostname, i can call external numbers from my extensions but the audio is missing.
If I set the external IP in SIP Settings address with my current IP address i can call external numbers and all work well.
I’m missing something?
P:S:
needless to say I’m behind a NAT
At the Asterisk command prompt, what does
dnsmgr status
show?
Did you restart Asterisk after changing External Address?
Is the trunk pjsip or chan_sip? Freepbx and Asterisk version?
DNS Manager: enabled
Refresh Interval: 120 seconds
Number of entries: 0 (before, when i last checked, was 2 number of entries)
yes
the trunk is pjsip.
Asterisk version: 16.15.1
Freepbx Version: 15.0.17.21 (just updated)
Sorry, in previous post, the dnsmgr status was for the configuration in which I have set up the external IP address not my external dynamic hostname.
If I set my external my dynamic FQDN hostname in external IP address the dnsmgr status reports: Number of entries 2
… But wit this setting no audio.
I’m puzzled.
With Asterisk SIP Settings -> External Address set to your FQDN, after Submit and Apply Config, what shows up in /etc/asterisk/pjsip.transports.conf ? I would expect to see
external_media_address=yourfqdn
external_signaling_address=yourfqdn
Then, does that name resolve correctly from the PBX? If not, do you have an incorrect entry in /etc/hosts ?
1 Like
This is the culprit!
my FQDN resolves to 127.0.0.1!
In order to generate a certificate with let’s encrypt I had to set the hostname of the machine with the FQDN. By doing so I have now found that freepbx also modifies the /etc/hosts file which I don’t think is correct.
Thank you very much Stewart!
I think the way freepbx updates the hostname, also changing the /etc/hosts file, should be corrected. For the moment I have reset the hostname in freepbx to my local hostname (which is also resolved by my local DNS server) but I fear that when freepbx will update the let’s encrypt certificate it will fail.
Unfortunately the “self check” code is buried in the 3rd party Lescript.php library. I doubt Sangoma will hack that code.
The easiest work around is adding the fqdn to the hosts file and point to 127.0.0.1 (no need to change host name itself), but that will still mess with dnsmgr.
The easiest dnsmgr friendly option is an iptables rule to redirect http requests back to localhost.
If using the FreePBX firewall with responsive lerules enabled:
iptables -t nat -A OUTPUT -p tcp -d mirror1.freepbx.org -m set --match-set lefilter dst -j ACCEPT
iptables -t nat -A OUTPUT -p tcp -m set --match-set lefilter dst -j REDIRECT
The above rules allow outbound requests to mirror1 for the lechecker.php process to complete, and redirects all other http requests back to the local interface.
Because it hooks into the responsive lerules “lefilter” ipset, the redirect is only applies during an active letsencrypt request.
Sorry jerrm, would you say that freepbx, when the hostname is set, modifies the hosts file just to allow the generation and updating of letsencrypt certificates? From my point of view editing the hosts file in this way is wrong.
Anyway thank you very much for your suggestions.
In no way is editing a hosts file “way wrong.” It’s why the file exists. But as I said, the hosts file method won’t play well with dnsmgr.
The iptables redirect method shouldn’t require any hosts file or dns mods.
I don’t know, but there are the DNS servers to resolve FQDNs and make these changes under the hoods is wrong.
These guys do know,
the hosts file provides fine tuning that a public DNS server can’t do, but you can use bind9 and build your own DNS server that does allow local names be resolved correctly.
I also. My public FQDN is managed by the servers of DynDNS and I not want that someone, also Freepbx hack my hosts file to point my FQDN to the loopback address.
You can edit /etc/nsswitch.conf and remove the mdns and hostname bits but you will not be able to use any names inside your network anymore.
If anyone can ‘hack my hosts file’, you have a very much bigger problem you need to resolve first.
I know the nsswitch.conf file. Maybe I have not explained myself, there is already a DNS that resolves my FQDN and it is also public. Why edit the hosts file?
There are a bunch of other reasons that suggest not editing the hosts file in this way.
Btw: I’have my localDNS server which resolves hostnames on a local domain but this is another story.
Some might counter argue that there a bunch of good reasons to edit /etc/hosts, in this particular case so your acme client actually works inside your network. If FPBX is messing with /etc/hosts , just make it immutable.
1 Like
From the point of view of a freepbx user, who wants to solve everything from the web gui, these solutions seem to me to be hacks to solve hacks.
Prepared to be corrected, but I don’t think FreePBX ever writes to /etc/hosts beyond maybe one time during install. I don’t believe it has permission to do so thru sysadmin.
All they are doing is adding the hostname. Technically not necessary if dns and firewalling is properly configured - but that is a huge “if” from a support standpoint.
I’m sure having it there has reduced the support burden than if it wasn’t there.
The GUI cannot be all things to all users. Some things, particularly OS level config, is only possible outside of the GUI.