[Solved] FreePBX vs pfSense - Trunk is now UNREACHABLE!

General Help
,
1

Hi,

I’ve recently set up a new FreePBX server, (latest FreePBX distro, Asterisk 11/64 bit). It’s all works just great, incoming/outgoing, IVR, recording everything. Until I get a –

[2017-06-19 09:12:38] NOTICE[22522] chan_sip.c: Peer ‘sip-out’ is now UNREACHABLE! Last qualify: 24
[2017-06-19 09:12:38] NOTICE[22522] chan_sip.c: Peer ‘sip-in’ is now UNREACHABLE! Last qualify: 24

in the full log and then I’m cut off from my SIP trunk provider. Asterisk then just sits there and doesn’t reconnect, and everyone gets “All circuits are busy” messages. Then the shouting and screaming starts. This can be from every a couple of days down to 10 mins.

I’ve been tearing my hair out for the last days, reading everything regarding having Asterisk/FreePBX connected via pfSense. I already had NAT rules in place to forward incoming requests from my SIP trunk provider through the firewall/NAT to the FreePBX VM.

I’ve since tried 1:1 NAT, didn’t seem to help, and then an Outbound NAT rule as recommended in the pfSense docs. This doesn’t seem to help either.
I’ve added ‘keepalive=30’ in the trunk settings, registertimeout and registerattempts, no improvement either.

I’ve tried using SIPROXD on pfSense, but the outbound traffic didn’t seem to go through the proxy. And the docs seem to infer that I shouldn’t be using it anyway.

I’ve spoken to the SIP Provider and they tell me I’ve jumped ports, instead of connecting to 5060 at their end, I was connecting to 38000ish. An ‘aportal restart’ seems to fix the issue, but of course that kills all active calls.

I’m guessing this is NAT time out issue, but I’m damned if I can find an answer, but I can’t be the only person with a SIP provider who uses IP based authentication (if that’s the right term where there is no username/password), who’s using FreePBX behind pfSense.

Oddly, I also have another trunk that I used for testing, it’s a traditional SIP setup with a username/password, and has no firewall/NAT rules in pfSense, but just works, this hasn’t dropped out that I’ve noticed.

Can anyone help? I’m at my wits end and getting a lot of heat from the management… :frowning:

Leee

2

Did you try putting the NAT outbound in hybrid mode and setting “Static Port” on with a custom mapping? I had to do that with Flowroute.
https://support.flowroute.com/customer/en/portal/articles/1852969-configure-pfsense-firewall

3

Do you have a static IP and/or subnet from your ISP?

4

Absolutely, two port forwards bringing the inbound 5060 & 10000-20000 from the trunk provider into FreePBS, and an outbound NAT with Static port to take 5060 out from FReePBX to the trunk provider. I’ve got mine set up as Manual Outbound NAT as the docs say, rather than Hybrid. Would that help?

5

Yes, I get a static IP from my ISP, they don’t tend to give out subnets here in the UK with a lot of cash being involved:)
The SIP trunk provider has also give me static IP of their server too.

6

I don’t think so as I got the same result from manual and hybrid.
Although I did not have to allow 5060 inbound with Flowroute. Just 10000-20000 UDP inbound.
Wish I could be more help but I am by no means an expert.

7

Just one question, if you don’t allow 5060 inbound, how does it get in? Surely the FW blocks it?
Unless it’s responding to the outbound 5060 maybe?

8

The PBX initiates the connection on port 5060 to flowroute and establishes a 2 way connection. I do not explicitly block 5060 but I do not port forward it on the wan either.

9

Riiight…
This got very ugly very quickly, ending up with the phone system being completely down for a day, and all the screaming and shouting that that involves… :frowning:

In summary –

The SIP peer being unreachable, was due to Fail2Ban (running on the FreePBX server - not on pfSense) banning the IP address of our SIP trunk provider.

The total ban was due to Recidive (part of Fail2Ban) banning the IP address for an extended period, because the SIP part of Fail2Ban was banning it intermittantly,

The reason that restarting FreePBX seemed to fix the problem, was due to the Fail2Ban ban timing out (and removing the firewall rule blocking the ITSP’s IP address), it was nothing to do with the restart.

Occasionally, restarting FreePBX didn’t work, but restarting our pfSense firewall got it working, again, this was nothing to do with restarting pfSense, it just took another 2 mins which gave Fail2Ban more time to timeout and remove the ban.

The reason why Fail2Ban was banning our ITSP’s IP Address was because they where “Friendly Scanning” our IP address on port 5060 thus -
Executing [nnnnnnnnnnn@from-pstn:2] Log(“SIP/sip-in-0000005d”, “WARNING,Friendly Scanner from nn.nn.nn.nn”) in new stack

Now they aren’t actually scanning us really. But looking at the line above that on a really wide terminal window it says -
Executing [nnnnnnnnnnn@from-pstn:1] NoOp(“SIP/sip-in-0000005d”, “Catch-All DID Match - Found nnnnnnnnnnn - You probably want a DID for this.”) in new stack

This is eluded to in various posts, but no one has actually ever said -
“DON’T USE THE ‘ANY’ DROPDOWN FOR DID ON YOUR PRIMARY INBOUND ROUTE - PUT YOUR DID NUMBER IN THERE!!”

When you do, the CatchAll line turns into -
_Executing [nnnnnnnnnnn@from-pstn:1] Set(“SIP/sip-in-00000665”, "_DIRECTION=INBOUND") in new stack

And the Friendly Scan line disappears. No processing from Fail2Ban, no banning, no rebanning from Recidive, SIP Trunk stays, up phone calls continue to go in/out. No screaming, no shouting, more time to drink coffee and do more interesting things…

I hope that helps another poor unfortunate who get caught up in this nightmare! :slight_smile:

10

Mark it as the solution.

11

Done.