I have a system that I am trying to use Zulu on. It sits behind a Cox fiber connection that has a single static wan ip, within that static wan ip it is then broken down in 5 IPs. I can access the system remotely using one of the 5 IPs within the Cox static. But when you press detect network settings in the system you see the single Cox IP. This prevents my certificate from creating because my fqdn doesn’t resolve to the static Cox IP. Is there a way to make this work?
With certman, the Let’s Encrypt hostname for the cert needs to resolve both internally and externally to the pbx address.
If your router/firewall doesn’t do nat loopback, the easiest option is probably to add the fqdn to the pbx’s host file pointing to 127.0.0.1.
1 Like
Huh? 
You have a Cox static block with five addresses in it. Are those routable or non-routable? Is the Cox cablemodem acting as a NAT Firewall?
I’m not sure what you’re asking. If you can access the server with one of the addresses, that should be the address in your DNS that points to that server. The “Detect Network” button is a blunt instrument and doesn’t always take into account the subtleties of the local network. Make sure you use “the right” address wherever you need to to get the box set up correctly.
1 Like
Probably a stupid questions but one I’d love to learn from - How do I add the fqdn to the pbx host file pointing to 127.0.0.1
Log in as ‘root’.
Learn to use ‘vi’. (It’s easy once you’ve used it for a couple of decades).
Use the following command:
‘vi /etc/hosts’
Add your entry at the bottom of the file.
1 Like
This is kind of a confusing file to edit. Let’s say my hostname is yes.yes.org and i want it to resolve to 8.8.8.8 how would you go about adding that and do I need to restart anything for this to take effect once added?
It current looks like this:
127.0.0.1 yes.yes.org localhost localhost.localdomain localhost4
::1 yes.yes.org localhost localhost6
If you want to set up a name that resolves to ‘1.2.3.4’, the entry is:
1.2.3.4 yes.yes.com
Note that the /etc/hosts file is another blunt instrument. If your system hits other resolvers first, the hosts file will not be used. You can add as many address/name pairs as you want, and you can repeat as many addresses as you want. The file is read until a match occurs, so in this example, yes.yes.com would resolve to 1.2.3.4, but yes.yes.org would resolve to 127.0.0.1. The hostname ‘localhost’ also resolves to 127.0.0.1
As far as I know, you don’t need to restart anything for the file to be active.
1 Like
I feel like I’m close but I keep getting the LE error:
There was an error updating the certificate: Error ‘Requested host ‘yes.yes.org’ does not resolve to ‘70.169.207.80’ (Resolved to ‘184.180.20.12’ instead)’ when requesting http://yes.yes.org//.freepbx-known/ef3be0f2137df0133577bf9e3ae8c76d
my etc/hosts file looks like this:
127.0.0.1 localhost localhost.localdomain localhost4
184.180.20.12 yes.yes.org
184.180.20.12 is the correct address for the fqdn and the one it should resolve to.
70.169.207.80 is the tunnel address of the Cox CIDR block of routable IPs
Your hosts file is only for your host. The rest of the Internet uses the distributed DNS.
Pedantic point - yes.org isn’t a hostname; it’s a domain name.
Whoever is hosting your DNS needs to update the entries so that the resolution of your ‘yes.org’ addresses resolve to the correct address. You should probably also create a specific hostname for your pbx host (like “pbx.yes.org”) and resolve that name to the specific address you are trying to hit.
In my attempt to simplify it appears i created more confusion! ha. yes.yes.org is registered and does resolve to the correct wan ip. It’s just when the server checks to see it’s external ip it resolves to something different than what it should. At the root level if I ping yes.yes.org it does resolve to 184.180.20.12 which is correct. So odd.
No offense, but it resolves to something you didn’t expect. It makes perfect sense to me.
Your network, yes.org, is the the network your specific host names are associated with, so technically, yes.org would be the router (behind which all of the yes.org hosts live) and the specific host name would resolve to the hosts behind that router and within that domain. The refers back to the ‘pedantic’ part of the message above - while you can think of ‘yes.org’ being a fully qualified domain name, it technically isn’t since there are FQDNs under it - yes.org becomes a qualified domain name (the fully part being the important bit that changes.)
I guess I’m confused because I’ve used google DNS to setup numerous LE certificates. I create a hostname, set the IP I want it to go to. In this case the hostname I created does resolve to the IP I tell it to. Google DNS is doing it’s job. Even in the system itself when I ping the hostname it resolves to the correct wan ip. But when I go to create my certificate it tells me the system is seeing a different wan ip. I’ve updated the hosts file so the hostname resolves to the correct address, I’ve even updated the local DNS servers to give the corrent wan ip for the hostname. Maybe a reinstall of the certificates module?
Very simply. . .
Who are you using for your name service?
At that organization, is there a ‘cname’ or ‘a’ record for yes.org or @.yes.org ?
is there a ‘cname’ or a record for yes.yes.org?
What are they?
Please try my original suggestion and replace the above with:
127.0.0.1 yes.yes.org
90% odds that will resolve the LetsEncrypt issue.
As to why the box doesn’t think it’s on the public IP - does the box have the public 184.180.20.12 assigned to an interface or is traffic for that IP being forwarded to it through NAT? If it has the public IP assigned to an interface is the default route through the same net/interface?
1 Like
Same error message. There is no external ip assigned to an interface. I think the issue is when the system runs a fwconsole extip it receives a different IP than what the hostname resolves to. I think the hostname resolves correctly now but the system itself when it looks for an IP it receives the wrong address and that mismatch kills the certificate.
From the local IT with regards to the IP scheme -
The 70.169.207.80 address is just the tunnel address for the CIDR block which is the 184.180.x.x IPs. It is not a usable address, but that is what the CIDR block appears to come from and always will. So every device within the network including the phone system will appear to come from the .80 which is causing a conflict with the certificate.
This is 100% a FreePBX problem, not a LetsEncrypt problem. FreepBX is trying to be too smart for it’s own good.
There is useless phone-home code to mirror1.freepbx.org in the certman module where FreePBX makes some idiotic assumptions about valid network configs.
At approx line 649 in /var/www/html/admin/modules/certman/Certman.class.php (certman 15.0.25.3) there is an if stanza that starts:
//check freepbx.org first
if($needsgen) {
$basePathCheck = "/.freepbx-known";
Disable this if statement by changing to:
//check freepbx.org first
if(0) {
$basePathCheck = "/.freepbx-known";
Save the changes and try the cert generation.
Then after confirming it works file a jira bug report asking what the #$&*!!! they were thinking.
2 Likes
my guess is you have a /29 subnet from your provider, the first is your “netweork” and unusable as a host as you found, the last is used for “broadcast”, your router will usually take the first or last address in the remaining six and award the other five in its dhcp service, . Use a one too one nat passthrough rule similarly if necessary and the router cant be bent to nicer behavior.
The likely solution is to statically assign the pbx to one of the 5 available and either reconfigure your routers dhcp service or just hope it is not too stupid and so not assign an ‘in use’ address
Set your nameservice and your acme client (incorrectly often called LetsEncrypt) to use that ip address
1 Like
Thank you! I have no idea how you found that. I’ve run into this situation on more than one occasion, never to this degree though. I really appreciate everyone’s help on this one.
I would tend to agree with @dicko a proper solution would be a proper one-to-one nat, or just assigning the IP directly, but… there isn’t anything explicitly wrong with your config. It becomes a discussion of best practices, other requirements, and preferences.
I can think of several very valid scenarios where the outbound request IP and the resolvable fqdn IP would differ. Evidently the LetsEncrypt/acme protocol folks agree as they don’t impose such a restriction.
The check FreePBX imposes is just dumb. If the desire is providing a debugging aid, then do the check only after a cert request failure.
That is another very good reason to use DNS01 as your acme protocol that way you can get your certificate without even knowing the ip of the PBX