Another Firewall Question

(Greg Snover) #1

Ok - I use DDNS for my Office and Home - I have added the fqdn to the Trusted Networks and it lets me in just fine - but when I go into Firewall, this banner is at the top of the screen:

The client machine you are using to manage this server (X.X.X.X/32) is not a member of the Trusted zone. It is highly recommended to add this client to your Trusted Zone to avoid accidental lockouts.

Except it is - my fqdn resolves to that IP.

I found this:Firewall trusts only IP addresses, but not hostnames - FreePBX - FreePBX Community Forums

but it’s not really my problem - I can connect and use the box just fine from that IP, I just get the message incorrectly - Is there a fix for this, or is it just a result of the way it looks at where you are coming from?

(Defcomllc) #2

You don’t add your FQDN to the trusted zone… your FQDN (your ddns address I assume) resolves to your Dynamic WAN IP…your hardware gateway/firewall/router then forwards traffic via Port forward, arriving at the WAN to your FreePBX…

You add the trusted LAN ip or entire LAN subnet that your pc is sitting on (presumably same subnet your freepbx sits on) to the trusted zone in Networks…if you have multiple subnets, vlans, VPN subnets that should be trusted you add all them as trusted networks as well. If your SIP trunk provider gives you IP’s to whitelist you add them to trusted networks as well…sangoma Connect you add a bunch more to trusted networks…you also whitelist the same in intrusion detection as well…

(Greg Snover) #3



Lorne specifically says in the Video that you can use a HostName:

I think it is just mis-reporting the machine not being trusted because it is in as the fqdn instead of the ip/32.

(Defcomllc) #4

A host name would be the hostname of the computer your connecting to the FreePBX GUI from…not a FQDN

(Lorne Gaetz) #5

I suspect you are correct, the check that determines if the IP you’re browsing from is trusted, is not looking for an FQDN. I will attempt to repro this, but if you want to file a ticket, go ahead. As long as the unnecessary warning is the only issue, it will get a lowish priority.

(Greg Snover) #6

Agreed, and I don’t think it’s a high priority either - just on the “To Do” list the next time somebody looks at the Firewall Module - Which is awesome by the way - I wish I had bit the bullet a LONG time ago and implemented this - I REALLY like it, and we are very enthusiastic about Security for our systems - the more the better.

(Greg Snover) #7

From the perspective of the FreePBX box, hostname = fqdn when browsing behind NAT on a connection that has a Hostname (A record) for it’s public IP.

I have a Comcast Connection = DHCP. But I have my SonicWALL configured for DynDNS - so no matter what my IP changes to, DynDNS is updated within seconds when it changes to the new IP. Which is why we use DynDNS - Comcast doesn’t change my IP nearly as often as they used to, but it still changes about every 120 days - if I set up all my boxes to allow the fqdn of the connection (my DynDNS name) then no matter how often it changes, I will always be “Trusted” when I hit the box from behind that IP.

Same thing for my Customers Premise connection - I almost never pay for a Static IP - I use DynDNS and I don’t need to.

(Defcomllc) #8

This is not how I have my FreePBX test box setup behind a Dynamic WAN IP using DDNS FQDN and I have no warnings on my WEBGUI Dashboard… Im not even sure why you would add your FQDN (Public WAN IP) to the Networks Trusted Zone either…

I run pretty much the same setup as you for 1 of my FreePBX test boxes with a VerizonFIOS DynamicIP and also use DDNS that autoupdates via the update module built into Untangle Commercial NG Firewall. Same setup as you just using Untangle instead of SonicWall… VerizonONT > Untangle NG Firewall> 48 Port Switch> Configured VLANS>VOIP VLAN>FreePBX sits on VOIP VLAN.

Your PC that your logging into the FreePBX webgui from… where you’re seeing the non-trusted message about the PC your using to access the webgui… Is it on the same local LAN subnet as your FreePBX box? Or are you accessing the FreePBX webgui remotely?

If youre accessing the WEBGUI from your local LAN subnet, you need to add that subnet (or at the very least the IP address of this computer) to your Networks tab and set to trusted… Your PC behind SonicWall is assigned or set statically a LOCAL LAN IP… It doesnt get your PUBLIC WAN IP which is why your still seeing that message…

Now, if your connecting to the webgui remotely, then thats a whole different setup. I use Wireguard VPN, and the VPN IP Subnet that Wireguard hands out to connecting VPN clients is set to Trusted in Networks and Whitelisted in Intrusion Detection and I also dont get any untrusted messages in my WEBGUI dashboard.

All of this is setup as outlined in the FreePBX Security Best Practives WIKI

(Lorne Gaetz) #9

@defcomllc the issue here has really nothing to do with the PBX network config at all. Greg is browsing to the admin GUI from a source IP that is whitelisted, but it’s whitelisted by FQDN, not by IP or subnet. For this reason, the warning is displayed when browsing to firewall. This is a supported configuration, but there’re lots of ways to achieve the same end result, which is ensuring that the Admin GUI is only accessible by trusted sources.

(Jared Busch) #10

This has always been like this.
How can anyone on the FreePBX team not know this?

(Lorne Gaetz) #11

Not saying nobody is aware, but I don’t recall it being discussed here. I know enough not to rely on my memory for this. If a ticket has been filed, I can’t find it, tho there is a very similar case reported (and resolved) in FREEPBX-14207

(Greg Snover) #12

Just to amplify what Lorne is saying - my customers PBX’s are at our CoLo facility - so NOTHING is local to them - no phones and no Admin - they are in effect “Cloud” - so I have to trust the Public IP’s of our Office and the Customers offices so that we can use and access the box.

I have transparent VPN access to the boxes, but I always want to access it from it’s public face to make sure it works like I think it should - hence hitting the box on it’s public address even though I could access it from it’s NAT address too.

(Defcomllc) #13

That answers my question, your accessing it remotely. I wont do it that way from a security standpoint…100% VPN to access the FreePBX box remotely but thats the way I do it. Phones, WebGUI, anything…

(system) closed #14

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.