AND ON TOP OF ALL THE BELOW…somehow, NetworkManager was getting loaded and on reboot somehow was being invoked. So the ultimate, ultimate resolution after days and days of trial and error and finally noticing a comment in passing in a two year old forum post and getting some misdirection to look at cloud-init was:
yum -y remove NetworkManager*
echo “exclude=NetworkManager*” >> /etc/yum.conf
re-run Firewall Wizard
So at the end of the day, NetworkManager getting loaded was the problem. All of the rest of the stuff below was simply symptomatic of a misconfigured network which the Firewall could not (and would not be expected to) properly resolve.
RESOLUTION: Instances which had been running on AWS EC2 were rebuilt. Since the time the servers were originally built, AWS went to a “all new builds default to VPC” environment. Suddenly I was behind a NAT. Changing SIP external address to PUBLIC and re-rerunning the resolved the problem which had absolutely nothing to do with cloud-init as was suggested in another location.
Here is the original PERCEIVED problem in case the symptoms feel familiar to anyone else…
Problem: FreePBX is functioning perfectly and handling calls except
Firewall is blocking GUI (reassigned to 58xxx in port management)
and SSH (reassigned to 58yyy in /etc/ssh/sshd_config)
Firewall Wizard does not properly assign external address to Firewall on AWS.
(and yes, I do type http://:58xxx and my SSH software is correctly redirected to 58yyy!)
This is an AWS cloud instance which has been functioning perfectly for over 14 months but the GUI & SSH became blocked - only for AWS - sometime in the 8 weeks prior to June 2018. Have spent two weeks trying to diagnose and searching for answers but am finally admitting the need for sage assistance from the fpbx community.
I have three other fpbx instances -
one ISO on Vultr
two installed with identical scripts to AWS on DigitalOcean.
All five instances update system and fpbx nightly via cron and are currently:
PBX Firmware: 12.7.5-1805-3.sng7
PBX Service Pack: 220.127.116.11
All users are (obviously) remote and none have problems connecting.
All instances have identical commercial modules installed and functioning.
Interfaces tab of fpbx Firewall:
Interface Name: dynamic Default Zone: Internet (Default Firewall)
IP Address: 172.31.xx.xxx/20
This is the correct IP assigned to eth0 by AWS.
This is a permanently assigned interface - does not change on reboot.
An Elastic IP (public) is assigned through DHCP - does not change on reboot.
AWS rewrites ifcfg-eth0 at every reboot of an EC2 instance to:
HWADDR=aa:bb:cc:dd:ee:ff (HWADDR static because of assigned network interface)
FPBX apparently creates an ifcfg-dynamic which contains
#Generated by FreeePBX Firewall. <<<Freee typo is not mine!>>>
#This file MAY BE CHANGED by the end user
I can find no documentation as to what I might put in here which could potentially address the html and ssh blocking by the firewall.
Results of [root@002 ~]# route -n
Kernel IP routing table
Destination___ Gateway____ Genmask____ Flags Metric Ref Use Iface
0.0.0.0______ 172.31.16.1__ 0.0.0.0______ UG__ 100__ 0__ 0__ eth0
172.31.16.0__ 0.0.0.0______ 255.255.240.0 U____ 100__ 0__ 0__ eth0
FreePBX splash screen shows correct hardware MAC and same
interface (internal 172.31.xx.xxx) as firewall - HOWEVER…
When running Firewall Wizard, answering “Yes” at every prompt
the CORRECT External Address of
34.218.xxx.xxx comes up and shows Known Networks of 172.31.xx.xxx/20
Asterisk SIP settings correctly picks up external address of
and detects correct Local Networks of
HOWEVER, the correct external address and eth0 does not populate to Interfaces, only the internal adapter address with a device name of “dynamic.”
I suspect that some slight enhancement in the Firewall between
April and June of 2018 has caused a hiccup in the AWS interpretations.
AWS support reports that their EC2 instance boot behavior has not changed.
The identification of the network interface as dynamic vs eth0 also started during this time period. Was previously always eth0 after wizard ran.
Is this a Responsive Firewall bug or SUI? (Sudden User Incompetence)
Have created bug report but will happily cancel if incompetence is demonstrated and resolved!