FreePBX | Register | Issues | Wiki | Portal | Support

Intermittent inbound call failure on trunk?

siptrunk
Tags: #<Tag:0x00007fafc23209a0>

(BrokenPaw) #1

Hi, all. I am new to FreePBX and PBX administration in general, so please forgive me.

I have been tasked with moving a (working) FreePBX/Asterisk PBX from direct internet to behind a NAT firewall (I know. But I have no choice).

I have it to where everything works…sometimes. Outbound calls from PBX extensions to PSTN numbers over a Twilio trunk work fine. Inbound DID calls work only some of the time.
When they succeed, the log reflects “Found peer ‘firewall-trunk-incoming’ for ‘+1calling number’ from 172.16.2.1:5060”
When they fail, the log reflects “Rejecting unknown SIP connection from 172.16.2.1”

172.16.2.1 is the interior IP of my firewall. I have a trunk set up in FreePBX with 172.16.2.1 set as a peer on the inbound side, and clearly the port forwarding on the firewall is letting stuff through.

What I don’t understand is why two calls, from the same PSTN phone, across the same trunk, across the same firewall, getting to the PBX from the same IP, are rejected as “unknown” some of the time, but accepted as a peer at other times. I can call twice from the same phone, literally ten seconds apart, and one will go through and reach the extension, and one will reject with “The number you have dialed is not in service”.

Any thoughts?


(Dave Burgess) #2

Relax - it’s no harder than anything else. You just need to keep in mind that NAT is more complicated and understand what it’s trying to do. Once you have the ball on that, it’s no more challenging than just running a normal “on the Internet” PBX.

You shouldn’t be seeing the Internal IP address for the firewall. You should be seeing the Twilio IP address as it should be passed through the Firewall. Once you have that fixed, you will need to make sure that the IP address block for Twilio is set up correctly in your PBX. IIRC, Twilio basically requires you to set up PJ-SIP (because of all of the possible IP addresses they send calls from).

Now, if you replace the 172.x.x.x address you are seeing with the actual address from Twilio and you don’t have all of the addresses set up in the Inbound Trunks, you will those messages.


#3

This is very strange. On a ‘normal’ router or firewall, forwarding a UDP port rewrites the destination address of an incoming packet (from the public IP of the firewall to the private IP destination specified in the forwarding setup). But the source IP address and port are unchanged, i.e. the PBX should see incoming INVITEs coming from a Twilio public IP address.

Most likely, there is a SIP ALG in the path (if your firewall has such a setting, try turning it off), or you have a very unusual forwarding setup. Firewall make/model? How did you set up the forward?

Also, note that Twilio sends calls (at random) from multiple IP addresses. Your trunk configuration should accommodate them all.


If it’s a pjsip trunk, simply list them in the Match (Permit) field. For chan_sip, you’ll either need to set up a trunk for each address, or use some custom dial plan.


(BrokenPaw) #4

I think you got it in one, cynjut.

The reason that my PBX was seeing the firewall’s internal IP was because (for reasons that are not germane) the IT folks set up a GRE tunnel directly between my PBX and the firewall host, and the firewall was NATting traffic that went into the GRE tunnel as well as traffic that was going out the public interface.

So inbound packets from Twilio were being forwarded to the PBX’s GRE IP, and then NATted so that they appeared to originate from the firewall. I got that NAT rule removed, and now the PBX is seeing the actual Twilio IP on the inbound packets, and everything is working now.

Thank you for the help!


(system) closed #5

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