BUG in latest firewall 14.0.3.6 ? - adding ip to Firewall Trusted Zone no longer updates Iptables Firewall Rules on firewall restart

So emailed Cyberlynk, they can reproduce the issue. Although fwconsole firewall trust <ip-address> shows that it in fact adds the ip to the trusted zone, the firewall itself does not add it.

this sounds like a new bug.

Even though I ran ‘fwconsole firewall trust 63.28.48.245/32’, I cannot access gui, as the rule does not show up in iptables, BUT,

if I run then this command: iptables -A fpbxnets -s 63.28.48.245/32 -j zone-trusted

I can then get in. Sounds like a bug.

This has always been the way - Adding entries via the command line require a firewall restart (as a malicious entity could potentially be adding a trusted entry). Just run ‘fwconsole firewall stop’ and then ‘fwconsole firewall start’

Forget to mention, I did do a firewall stop and start. This has also been confirmed as an issue by CyberLynk.

I believe it has been confirmed by Frank at CyberLynk, here is the email to me:

"This is very odd. I can see that you added 63.28.48.245 into trusted, but it’s not there in the iptables rules. I did it command line via:

fwconsole firewall trust 63.28.48.245/32
fwconsole firewall stop
fwconsole firewall start

And it’s still not there. I checked and your on the latest version of the System Firewall module. I’ll do some digging on the forum and FreePBX issues system, as I have not seen this one before."

Anybody able to try this against latest module updates? Its a quick test from command line.

fwconsole firewall trust
fwconsole firewall stop
fwconsole firewall start

iptables -L --line-numbers

Look for ‘fpbxnets’ chain, see if that is listed there.

Thanks

I tried adding ip to trusted zone on a backup machine, updated all modules and O/S updates, get same behavior. Iptables does not update.

Anyone else seeing this, I am not sure it’s a bug, or something in my pbx setup, but it just started very recently.

I just tested with Firewall 13.0.55.3 [edit - on FreePBX 13] and I have no issues. Using the following steps at the CLI, I successfully white listed an ip:

[root@pbx ~]# fwconsole firewall trust 66.185.28.100
Attempting to add '66.185.28.100/32' to Zone 'trusted' ... Success!
[root@pbx ~]# fwconsole firewall stop
[root@pbx ~]# fwconsole firewall start

after the above I was able to access the PBX where before I couldn’t. I am unable to confirm your report.

1 Like

Well thanks for the info. I am not sure which firewall version I have, everything is the latest.

I am on plane, and cannot access the pbx right now to check.

Are all your modules the most current?

Thanks for taking the time.

I am testing with the latest edge version on FreePBX 13. You may be slightly behind if you are on stable, but you can upgrade with:

fwconsole ma upgrade firewall --edge

I think we use Freepbx 14, I did edge upgrade too, thinking it might help, but it did not. Will check versions post plane ride later tonight.

Worked great until a couple days ago.

Frustrating.

firewall version is: 14.0.3.6

Same issue. If I add custom rules, I can get around this issue, but really seems like a bug.

framework, core and firewall are edge

Sangoma - when is fix expected?

ANYONE out there can confirm this in 14.0.3.6, or not? Thanks

Sorry but we aren’t able to replicate this

In Userland, I’m not able to replicate it either.

Y, that sucks, as I have no idea then what caused this issue, or how to correct it.

thankfully, custom iptable rules seem to accomplish the same thing, although not as cleanly.

Looks like another case emerged, there’s a ticket you ‘watch’ here for auto progress updates:
https://issues.freepbx.org/browse/FREEPBX-17632

Thx for the info, though I think it is somewhat more than a minor bug.

Priority means nothing.

This issue was bugging me, so I created a bash script that does the following, and responsive firewall is disabled.

For remote users, including travelers, created a noip host that gets checked every 5 minutes, seed the working directory with a file containing the initial ip address of each remote user, add a custom entry in /etc/firewall-4.rules.

Every 10 minutes via cron, query via dig the current ip based on the noip host name, if a difference exists between the seed file and current ip, iptables -A on the ‘new’ ip, and iptables -D on the ‘old’ ip; update the seed file with the new ip. Then update in place the /etc/firewall-4.rules file via sed.

Works well, so far, until the firewall issue is resolved.

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