You probably don’t need two trunks, but help us understand your setup a bit better.
When you say you have two extensions, are those SIP endpoints registering to FreePBX, or analog sets connecting to the gateway?
FreePBX + Digium gateway 2G402F?
Moving to a temp server while existing being rebuilt (licensing)
I have to agree with this. If one is either moving the deployment to a new machine (either because the old one isn’t fast enough or is failing), there should be zero penalty for explicitly deactivating the licenses on the first machine before activating them on the replacement machine. Penalizing your customer for doing performing what is a common maintenance procedure just is NOT COOL.
The only time I should have to beg Sangoma for the ability to activate a paid-for license on a new server is if the machine the deployment is licensed for was burnt so badly that it cannot cleanly communicate with them and cleanly release the licenses in preparation for the move. That’s where “zend resets” should be a limited “resource”, and only there.
At this point I haven’t even rolled out a new PBX to my church, and for some reason I’m already at 1 reset remaining. For various reasons learned in the process of setting up the system in the first place, I’m now planning on moving the deployment to a VM, which to my understanding will leave me with ZERO resets. If that VM becomes damaged in any way and requires a rebuild, I will be completely screwed until Sangoma deigns to give me another reset, which is not acceptable. More immediately, if I determine during the process of building the VM up that for one reason or another it ends up not actually being a good idea, I’ll be screwed again unless Sangoma takes pity on me. I must activate the VM deployment, because in order to even consider placing this PBX in the “cloud” I must have VPN functionality, which is a licensed feature. I also must be able to validate EPM functionality in relation to the VPN.
EVERY other “seat”-based licensing system out there (I’m specifically referring to things like $1M software packages used for e.g. chip design, etc.) has a continuous check-in/check-out mechanism, with zero penalties for moving the license. FreePBX should be exactly the same.
Inbound calls stop working, but outbound calls work
If I understand port forwarding correctly, only the trunk’s public IP addresses are allowed to access the FreePBX systems. However the SIPVicious scan came from the trunk’s public IP address. VoicePulse claims there’s no intrusion on their end, but I’ve taken that with a grain of salt. I’m redoing the entire system today, changing passwords, port numbers, using TLS, IP authentication, etc.
Moving to a temp server while existing being rebuilt (licensing)
We have no ability to know the license has been removed as we don’t have phone home stuff so even though we remove the license file on the machine we have no way to keep you from just putting it back from a backup and since we don’t force a phone home license update we have no way of truly taking back the license from the machine once it has it which is why we give you 2 resets but as we know their are plenty of abusers who run that same license on 2-3 machines using resets it does not make us want to give even more resets. If we move everything to 1 year license than it becomes a moot point.
"Works For Me" Status for issues
Note also if you can reliable reproduce an issue and provide steps to do so we will follow those steps. I had one that passed everyone’s testing because it only failed on Firefox and only if items were in a specific order. Without exact steps and environment we wouldn’t be able to confirm the issue. Every issue has to be reproducible to be solves. It’s like having 100 pieces missing from a thousand piece jigsaw puzzle. You have to assemble the other 900 before you know which hundred are missing. Programmers do one thing. We solve puzzles. If the puzzle is incomplete all we have is assumptions and we all know what they say about assuming.
The best bet most of the time is to post your issue on the forums first. Others may confirm if it is an edge case or a while spread issue. We obviously follow along here and if something is painfully obvious we direct people to open tickets. I can tell you if we send you to the ticket system it probably won’t close with the above status. Again when triaging this is not an arbitrary or punt status. We have teams that test these things. We try to confirm issues. When we don’t have enough to try we ask for feedback and try to solve every issue we can based on triage.
Some insight into the triage process
4 senior software engineers, a support lead and the QA and support manager discuss every ticket on Mondays. We keep a pulse on issues we see multiple users having. Things that QA and support has confirmed or needs to confirm etc. When you post to the forums and get multiple “Mee too” responses we may have it fixed the same day. People rely on us, often for business communication. We obviously rely on them as our business and passion. We really try to bend over backwards to make sure we are taking care of folks
FreePBX + Digium gateway 2G402F?
Google Voice no "ringback" when calling out?
You have to have CORE 14.0.5.16 or greater, that’s where the fix for this resides. You will have to delete and recreate all of your Google Voice accounts for it to work properly.
How I found this was using TCPDUMP on my Raspberry Pi (that is running FreePBX), i watched the traffic on the port for my phone to see what was going on. I then stuck an old MicroSD card in the Pi, booted it to an older FreePBX and did the same thing. That had the “ringing” and the newer version didn’t.
I think the command from the Linux command line is tcpdump -vvv port 5060 (or in my case it was Port 5160 since I’m not running PJSIP since it doesn’t seem to like my Cisco 79xx series phones too much.
What is the general experience using TCP instead of UDP?
The pure nature if TCP would make it more reliable than UDP, but also add some overhead, so just make sure you have enough bandwidth for it.
Inbound calls stop working, but outbound calls work
You shouldn’t need to open port 5060 to everybody, just IPs absolutely known to you, like your VoSP. If you are expecting external endpoints to connect to your FreePBX, then that’s another story.
Inbound calls stop working, but outbound calls work
The ports were forwarded to only allow VoicePulse’s network through via those ports. What ended up happening was a SIPVicious scan came from one of those addresses within their network, allegedly.
Inbound calls stop working, but outbound calls work
I don’t have the best experience… But if you have your ports restricted to them, then they were the ones who got hacked, not you.
If someone hacks a SIP Provider, they gotta be crazy to try to connect to a PBX through the Trunk.
Freepbx 14 with PHP7 and mysql 5.7 in Centos 7
Do you know when PHP 7 will be supported?
Endpoint Manager changing config server to include tftp prefix
I’m trying to set up the endpoint manager to configure our gxp 2170s. I haven’t been able to get option 66 working, so I’ve had to go into each phone to configure the config server as the freepbx server. This works fine. I type in the ip and it grabs the config file. But after that, I’m not able to give it any more configs. The config changes the server address to include the tftp://, and as far as I can tell, this is preventing it from grabbing any more updates. Is there a way to not include this prefix in the config? I know on another system I manage, epm doesn’t seem to add that prefix, so maybe I can fix this by downgrading epm. What are your thoughts?
Inbound calls stop working, but outbound calls work
That’s exactly what I’ve been trying to tell VoicePulse but they insist it was on my end and not theirs. But the SIPVicious scan came through their network and the intruder has made some calls at our expense.
Endpoint Manager changing config server to include tftp prefix
fwconsole ma --edge upgrade endpoint
Endpoint Manager changing config server to include tftp prefix
It appears to be getting stuck at: “Checking settings and defaults.” And now the module is disabled.
Inbound calls stop working, but outbound calls work
Maybe not. Note that according to RFC3261, the response to a SIP request that does not have an rport tag in the Via header will be sent to the address/port in Via, not the address/port that the request came from. So, an attacker with the ability to spoof the source IP address could bypass your whitelist and still have the response sent to his IP address.
This is difficult because most data centers and ISPs filter outbound packets whose source address is not assigned to them. The attacker would either need to use a data center without such filtering, or have a server in a center used by VoicePulse.
If you have packet captures of some of the SIPVicious traffic, you can determine whether this actually happened.
Inbound calls stop working, but outbound calls work
This is serious social engineering, if this is the case then i suggest you hiring a InfoSec professional and purchase some protection services, including a nice upgrade to your firewall. Otherwise, it WILL happen again.
I still believe that your SIP ports were/are not full locked down, I’d run a port scan with nmap against your public IP, see what ports are open etc.
Help, FXO cannot make external calls
Please help.
We have an old analogue Panasonic KD-TDA100D with 20x analogue phones in the office. We’re moving some users to a new office. The two building have a good wireless link to share internet and network services like printers, servers, etc. The extensions on the Panasonic PBX run from 101 to 127 (some extensions are inactive). 10 of the staff need to go to the new building.
So I installed FreePBX 14.0.1.24 on a new server in the new building and we’re going to purchase some new SIP phones, and also setup something like Linphone or Zoiper on some of the users’ mobile phones. I have the extensions of the users moving into the new building setup in FreePBX and on their mobile phones (have not decided on SIP phones yet) and this works very well.
Then I have some Grandstream HT503, Grandstream HT802 and HT704 ATA gateways to extend their extensions to the new building via the VPN.
I don’t have access to the Panasonic PBX, nor can we replace it at this stage. I setup FreePBX and the Grandstream HT-503 FXO as per this article
The problem is, when I attempt to dial one of the existing extensions on the Panasonic PBX, using the FXO port, I get an engaged signal - on all the numbers I tried to phone, even though I know the phones are not engaged.
When calling 102, which still remains on the Panasonic PBX, from 112, which is a newly created extension in FreePBX, I get the following on the Asterisk console:
<— SIP read from UDP:192.41.100.31:5062 —>
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP 197.184.153.199:5160;branch=z9hG4bK4e177ce2;rport=5160;received=192.41.100.240
From: “Mariska” sip:114@197.184.153.199:5160;tag=as17d893a0
To: sip:102%40112-1@192.41.100.31:5062;tag=270990891
Call-ID: 1dcd9e4a1ce2320f7a0d290c61d1992f@197.184.153.199:5160
CSeq: 102 INVITE
Supported: replaces, path, timer, eventlist
User-Agent: Grandstream HT-503 V2.0A 1.0.15.5 chip V2.2
Warning: 399 GS “All channels are in use”
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0
<------------->
— (11 headers 0 lines) —
– Got SIP response 486 “Busy Here” back from 192.41.100.31:5062
Transmitting (NAT) to 192.41.100.31:5062:
ACK sip:102%40112-1@192.41.100.31:5062 SIP/2.0
Via: SIP/2.0/UDP 197.184.153.199:5160;branch=z9hG4bK4e177ce2;rport
Max-Forwards: 70
From: “Mariska” sip:114@197.184.153.199:5160;tag=as17d893a0
To: sip:102%40112-1@192.41.100.31:5062;tag=270990891
Contact: sip:114@197.184.153.199:5160
Call-ID: 1dcd9e4a1ce2320f7a0d290c61d1992f@197.184.153.199:5160
CSeq: 102 ACK
User-Agent: FPBX-14.0.1.24(13.19.1)
Content-Length: 0
-- SIP/114-1-00000035 is busy
== Everyone is busy/congested at this time (1:1/0/0)
– Executing [s@macro-dialout-trunk:32] NoOp(“PJSIP/114-00000161”, “Dial failed for some reason with DIALSTATUS = BUSY and HANGUPCAUSE = 17”) in new stack
– Executing [s@macro-dialout-trunk:33] GotoIf(“PJSIP/114-00000161”, “0?continue,1:s-BUSY,1”) in new stack
– Goto (macro-dialout-trunk,s-BUSY,1)
– Executing [s-BUSY@macro-dialout-trunk:1] NoOp(“PJSIP/114-00000161”, “Dial failed due to trunk reporting BUSY - giving up”) in new stack
– Executing [s-BUSY@macro-dialout-trunk:2] PlayTones(“PJSIP/114-00000161”, “busy”) in new stack
– Executing [s-BUSY@macro-dialout-trunk:3] Busy(“PJSIP/114-00000161”, “20”) in new stack
== Spawn extension (macro-dialout-trunk, s-BUSY, 3) exited non-zero on ‘PJSIP/114-00000161’ in macro ‘dialout-trunk’
== Spawn extension (from-internal, 102, 7) exited non-zero on ‘PJSIP/114-00000161’
– Executing [h@from-internal:1] Macro(“PJSIP/114-00000161”, “hangupcall”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“PJSIP/114-00000161”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,3)
– Executing [s@macro-hangupcall:3] ExecIf(“PJSIP/114-00000161”, “0?Set(CDR(recordingfile)=)”) in new stack
– Executing [s@macro-hangupcall:4] NoOp(“PJSIP/114-00000161”, " monior file= ") in new stack
– Executing [s@macro-hangupcall:5] AGI(“PJSIP/114-00000161”, “attendedtransfer-rec-restart.php,”) in new stack
– Launched AGI Script /var/lib/asterisk/agi-bin/attendedtransfer-rec-restart.php
– <PJSIP/114-00000161>AGI Script attendedtransfer-rec-restart.php completed, returning 0
– Executing [s@macro-hangupcall:6] Hangup(“PJSIP/114-00000161”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 6) exited non-zero on ‘PJSIP/114-00000161’ in macro ‘hangupcall’
== Spawn extension (from-internal, h, 1) exited non-zero on ‘PJSIP/114-00000161’
– PJSIP/114-00000161 Internal Gosub(crm-hangup,s,1) start
– Executing [s@crm-hangup:1] NoOp(“PJSIP/114-00000161”, “Sending Hangup to CRM”) in new stack
– Executing [s@crm-hangup:2] NoOp(“PJSIP/114-00000161”, “HANGUP CAUSE: 17”) in new stack
– Executing [s@crm-hangup:3] ExecIf(“PJSIP/114-00000161”, “0?Set(__CRM_VOICEMAIL=)”) in new stack
– Executing [s@crm-hangup:4] NoOp(“PJSIP/114-00000161”, “MASTER CHANNEL: 1523829540.407 = 1523829540.407”) in new stack
– Executing [s@crm-hangup:5] GotoIf(“PJSIP/114-00000161”, “0?return”) in new stack
– Executing [s@crm-hangup:6] Set(“PJSIP/114-00000161”, “__CRM_HANGUP=1”) in new stack
– Executing [s@crm-hangup:7] AGI(“PJSIP/114-00000161”, “sangomacrm.agi”) in new stack
– Launched AGI Script /var/lib/asterisk/agi-bin/sangomacrm.agi
– <PJSIP/114-00000161>AGI Script sangomacrm.agi completed, returning 0
– Executing [s@crm-hangup:8] Return(“PJSIP/114-00000161”, “”) in new stack
== Spawn extension (from-internal, h, 1) exited non-zero on ‘PJSIP/114-00000161’
– PJSIP/114-00000161 Internal Gosub(crm-hangup,s,1) complete GOSUB_RETVAL=
Really destroying SIP dialog ‘1dcd9e4a1ce2320f7a0d290c61d1992f@197.184.153.199:5160’ Method: INVITE
[2018-04-15 23:59:12] NOTICE[20338]: res_pjsip/pjsip_distributor.c:649 log_failed_request: Request ‘REGISTER’ from ‘“Server Room” sip:144@192.41.100.240’ failed for ‘192.41.100.160:5060’ (callid: aa15fbe-89f29be1-13603d7c@192.41.100.160) - No matching endpoint found
[2018-04-15 23:59:12] NOTICE[8340]: res_pjsip/pjsip_distributor.c:649 log_failed_request: Request ‘REGISTER’ from ‘“Server Room” sip:144@192.41.100.240’ failed for ‘192.41.100.160:5060’ (callid: aa15fbe-89f29be1-13603d7c@192.41.100.160) - No matching endpoint found
[2018-04-15 23:59:12] NOTICE[8340]: res_pjsip/pjsip_distributor.c:649 log_failed_request: Request ‘REGISTER’ from ‘“Server Room” sip:144@192.41.100.240’ failed for ‘192.41.100.160:5060’ (callid: aa15fbe-89f29be1-13603d7c@192.41.100.160) - Failed to authenticate
The FreePBX Server IP is 192.41.100.240. The Grandstream FXO is on 192.41.100.31
Inbound calls stop working, but outbound calls work
IP spoofing was an idea I had in my head after the fact it happened. The plan for tomorrow is to lock down the firewall some more. Right now I’m rebuilding the FreePBX systems from scratch; stronger passwords, domain names instead of bare IP address, TLS, and IP authentication are high on the list. Once all that is finished and confirmed working I’ll go from there.