Good day!
I have a problem. We use Freepbx 17 (new installation) 1 interface DMZ 192.168.16.0/24
Phones 192.16.0.0/24
Both networks are local
Registration on devices is often lost, I see on tcpdump that the phones are sending a request, but nothing is sent back. Now a reboot of the machine helped, but the PBX is new, about 7 hours and 300 users
Howdy! Welcome to the forums.
That doesn’t look quite right.
This is probably the FreePBX 17 firewall being a little aggressive. You might try checking under Admin → System Admin module, also Connectivity → Firewall, looking at fail2ban settings, assigning interfaces to proper zones, and reviewing your overall network settings:
https://sangomakb.atlassian.net/wiki/x/PoCuFg
That temporarily pauses the firewall until about 5 minutes later, if you are running in Safe Mode:
What do you mean not quite right?
Firewall is disabled
This does not happen in 5 minutes.
Surprisingly, it did not appear during these 2 days.
192.16.0.0/24 is a block of public addresses. Perhaps you meant 192.168.0.0/24.
If the REGISTER requests show in tcpdump or sngrep, but do not appear in the Asterisk log, they were almost certainly blocked by FreePBX Firewall (or other software firewall you may be running). However, since these requests are good (they work properly when not blocked), I suspect that some other device or app on the same IP address is intermittently causing trouble.
When you have the issue, look at Connectivity → Firewall → Intrusion Detection for any banned IPs.
if you really have 192.16.0.0/24, thats obviously an error, it belongs to AS14153 a CDN which is limited in its peering table, explains why you go nowhere 
No, that’s a typo 192.168…
No, that’s a typo 192.168…
My firewall is disabled from the very beginning. So far, no problems have been observed. But there was strange behavior. When I see a request towards the PBX, but there is no response, and some were working
If the device has many codecs enabled, the request may exceed 1500 bytes and fragmentation might be handled incorrectly, causing the packet to be dropped. If that case, enabling only (for example) ulaw (A.K.A. PCMU or G.711u) and alaw (A.K.A. PCMA or G.711a) should fix it.
if you really have 192.16.0.0/24, thats obviously an error, it belongs to AS14153 a CDN which is limited in its peering table, explains why you go nowhere 
(lost post from 2025-03-18 07:18:17 restored by mod on 2025-03-22 and requested review by @nickzed)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.