Uploaded image for project: 'FreePBX'
  1. FreePBX
  2. FREEPBX-17683

Elastic/Flexible IPs

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Done
    • Affects Version/s: 14
    • Fix Version/s: None
    • Component/s: FreePBX GUI setting
    • Labels:
      None
    • ToDo:
    • Asterisk Version:
      13
    • Distro Version:
      12.7.5-1805-3.sng7
    • Distro:
      FreePBX Distro

      Description

      MYSTERY SOLVED - PROBLEM RESOLVED: NetworkManager somehow got loaded on the misbehaving instance.  Noticed a comment in passing in the forums about "NetworkManager fighting with the installation" and checked all instances.  Problem solved.  I am using SNG7 and Sangoma repos but this probably happened when I needed an application from another repo.  Because my maintenance is automated, it propagated across all installs - including my FreePBX ISO.  The following fixed and will prevent going forward.

      yum -y remove NetworkManager*
      echo "exclude=NetworkManager*" >> /etc/yum.conf
      reboot
      re-run Firewall Wizard (adapter named "dynamic" now correctly named eth0)

      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.

       

      The original problem is preserved below simply as a catalog of symptoms.  The actual problem (not Sangoma's issue) is that AWS is migrating all instances to NAT VPC.  The resolution was to change NAT settings to public (I have static public IPs to the NAT), delete local network info, re-run Discover Settings, save config, re-run Wizard, reboot instance. 

      HOWEVER - I still believe there is an anomaly in the Firewall wizard.  I have two identical instances of FreePBX running constantly updated SNG7 and multiple (identical) commercial modules also updated nightly both on the same VPC.  One of them - fortunately my primary production box - properly set eth0 with the internal network 172.xx.xx.xx IP, and the other one picked up all the correct numbers but set the adapter name as dynamic.  Interestingly, both instances created an ifcfg-dynamic, but one called itself eth0 (and works) on the Interfaces tab, and the other calls itself dynamic and functions as a PBX but blocks http and ssh.  Why two identical (built from the same build script, and updated concurrently) instances would behave differently in the Firewall Wizard is a mystery. 

      I could simply rebuild the misbehaving instance, but I would prefer to solve the mystery of identical twins behaving unidentically.

       

      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://<address>: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: 1.0.0.0
      FreePBX 14.0.3.6
      Asterisk 13

      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:
      BOOTPROTO=dhcp
      DEVICE=eth0
      HWADDR=aa:bb:cc:dd:ee:ff (HWADDR static because of assigned network interface)
      ONBOOT=yes
      TYPE=Ethernet
      USERCTL=no

      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
      ZONE=external
      DESCRIPTION="unset"

      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
      34.218.xxx.xxx
      and detects correct Local Networks of
      172.31.16.0/20

      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.

      Is this a Responsive Firewall bug or SUI? (Sudden User Incompetence)

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                chriskinsey Chris Kinsey
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  NextupJiraPlusStatus

                  Error rendering 'slack.nextup.jira:nextup-jira-plus-status'. Please contact your Jira administrators.