Looking for assistance with Responsive firewall blocking remote users

We are looking to hire a consultant to assist with understanding and resolving as to why the responsive firewall is blocking our remote users.

What phones are your remote users using? Are you open to using a VPN for the phones?

We’re using the following phones. I believe remote user’s only have the Polycom VVX400(listed the others for completeness).

  • VVX400
  • VVX410
  • IP5000 (conference)
  • Cyberdata Pager-Adapter-V3
  • Uniden exp1240

In regards to using a VPN(I’ve also seen DynDNS suggested), I’m not sure what the costs would be so hard to say. Our hope was we have a configuration problem of some sort that someone with more knowledge and experience could quickly find and fix, but at the end of the day as long as costs aren’t to high we would be open to setting up a VPN if that resolves the issue. Please note most of our end users are using Wireguard VPN for remote access to our network from their PC already…

Thanks,
Eddie

My recommendation is:

  • Determine if all your phones support the Wireguard VPN.
  • If yes, use the Wiregarud VPN and create a priority VLAN just for VoIP that the FreePBX can reach.

The phones have to be setup with the VPN upfront, but not much is needed after the initial setup and less back and forth with the firewall.

@comtech really appreciate your feedback!

In talking with the engineer that setup our phones he’s pretty reluctant to pursue a VPN(but open to it as a last resort), as I understand it sounds like a really big hammer to him. Keep in mind our phones don’t support any VPN…

Our hope is someone else on the forum has expertise with the responsive firewall that is open to consulting with us to understand why the responsive firewall is blocking our remote employees.

Do they initially connect then get blocked after some time?
It’s possible the registration is expiring, at that point the firewall sees traffic from the phone as invalid.
Check the qualify frequency on the devices, possibly shorten the time.

Do multiple devices share one wan ip? If so, all it takes is one to fail to block all, if the wan address is static, and trusted (ie in your control, with good security), you might consider adding it in the firewall’s networks tab as a trusted/excluded address. This would be a preventative measure, but you should still correct the actual issue at hand.

Definitely explore the logs to find where the failures are happening.

Thanks for the response!

I’m remote and have never experienced an outage. Keep in mind we don’t monitor for outages. Only way we know we have an outage is an end user reports it(usually trying to call someone and they can’t). We find the IP blocked, so we add it as trusted. That works until the DHCP address changes and they report an outage. Rinse and repeat…

Please note remote users work from home, so one WAN IP per phone.

I don’t have past experience with Asterisk, but have spent quite a bit of time digging through our verbose(9GB) logs, and reading about others with this same problem on the forums. Please note I see a lot of people talking about registrations, I don’t know what those messages look like in the logs, so don’t know to respond… Here is what I saw for the most recent outage we had - if you could help me to understand what this means conceptually or if you see a clue that would be extremely helpful.

Note: In /var/messages I found the iptables rules and in /var/log/asterisk I found the logs for ChallengeSent and SuccesfulAuth.

Normal behavior for an IP address:

  • ChallengeSent followed by SuccesfulAuth

Last Outage for an IP address:

  • ChallengeSent for about 10 minutes without a SuccesfulAuth
  • /sbin/iptables -w5 -W10000 -D fpbxregistrations -s xxx.xxx.xxx.xx/32 -j fpbxknownreg
  • User reported outage
  • new DHCP IP was listed as trusted
  • ChallengeSent followed by SucessfulAuth
  • /sbin/iptables -w5 -W10000 -A fpbxregistrations -s XXX.XXX.XXX.XXX/32 -j fpbxknownreg
  • Service reported as restored

Definitely related to failed registrations / lack of registrations.

My working theory (based on your statement of having to add a new ip as trusted) is the clients are experiencing ip changes, and phones are failing to register before their traffic (keep alives or other background traffic) gets blocked by the firewall. The phone doesn’t/can’t know the wan ip has changed, and will keep sending traffic blindly until it also notes the lack of response from the pbx.

Look backwards in the logs from for the first mention of an ip that’s been blocked, if it isn’t a registration attempt then likely this is what’s happening. Everything below is assuming that this is true, that the phone is sending traffic from a new address before re-registering.

On the devices you might need to adjust register expiration (or register frequency). I’m not sure how your devices are provisioned so I can’t direct you how to adjust them, but it looks like the default registration expiration on the VVX400 is 3600s (60 minutes), that could easily be turned down, My devices (looking at my EPM provisioned S500) are set to 900s (15 minutes), but even shorter wouldn’t be unreasonable.

You might also have a better experience using TCP or TLS instead of UDP, this might provide a shorter time from the connection breaking to it re-registering (as the device will have feedback that the connection is broken sooner), but that’s really just conjecture and down to implementation.

@SterlingPkg thank you so much, this is so helpful as I’m starting to gain a conceptual understanding of how this works!!!

Sorry dumb question, is this what a registration even looks like in the logs? I ask as they all indicate a failure… Also there were none of these entries for the IP of our remote employee when his phone was banned.

[2023-02-10 07:37:09] NOTICE[23600] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘128.90.164.17:58623’ (callid: e5f4a700616987e4f7a07) - Failed to authenticate
[2023-02-10 07:37:09] NOTICE[18144] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘128.90.164.17:58623’ (callid: e5f4a700616987e4f7a07) - No matching endpoint found
[2023-02-10 07:37:09] NOTICE[18144] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘128.90.164.17:58623’ (callid: e5f4a700616987e4f7a07) - Failed to authenticate
[2023-02-10 07:38:24] NOTICE[10838] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘20.64.248.71:51602’ (callid: e5f4a77066614e4f7a250) - No matching endpoint found
[2023-02-10 07:38:24] NOTICE[23600] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘20.64.248.71:51602’ (callid: e5f4a77066614e4f7a250) - No matching endpoint found
[2023-02-10 07:38:24] NOTICE[23600] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘20.64.248.71:51602’ (callid: e5f4a77066614e4f7a250) - Failed to authenticate
[2023-02-10 07:38:24] NOTICE[13594] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘20.64.248.71:51602’ (callid: e5f4a77066614e4f7a250) - No matching endpoint found
[2023-02-10 07:38:24] NOTICE[13594] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘20.64.248.71:51602’ (callid: e5f4a77066614e4f7a250) - Failed to authenticate
[2023-02-10 07:38:38] NOTICE[1847] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘128.90.102.31:59383’ (callid: e5f4a928193744e4f7a203) - No matching endpoint found
[2023-02-10 07:38:38] NOTICE[31115] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘128.90.102.31:59383’ (callid: e5f4a928193744e4f7a203) - No matching endpoint found
[2023-02-10 07:38:38] NOTICE[31115] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘128.90.102.31:59383’ (callid: e5f4a928193744e4f7a203) - Failed to authenticate
[2023-02-10 07:38:38] NOTICE[21392] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘128.90.102.31:59383’ (callid: e5f4a928193744e4f7a203) - No matching endpoint found
[2023-02-10 07:38:38] NOTICE[21392] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘128.90.102.31:59383’ (callid: e5f4a928193744e4f7a203) - Failed to authenticate
[2023-02-10 07:38:40] NOTICE[21392] res_pjsip/pjsip_distributor.c: Request ‘REGISTER’ from ‘sip:[email protected]’ failed for ‘128.90.187.224:56254’ (callid: e5f4a447737038e4f7a63) - No matching endpoint found