FusionPBX Restore from old server - Gateway Issue

Status
Not open for further replies.

krishanodedra

New Member
Jul 17, 2018
28
0
1
31
Hi All,

We had to migrate our FusionPBX server from one cloud provider to another and after running the backup/restore scripts with custom changes I am seeing phones successfully register, I am able to dial internally/outbound however incoming calls from the trunk seem to fail. I am NOT showing any activity from freeswitch when running sofia global siptrace on and I am making sure our provider is sending calls to port 5080 and just in case I have the provider listed in the ACL domains with IP/32. Our old cloud provider was able to provide the public IP address to the server however our new provider has to go through NAT so I changed the ext-rtp-ip and ext-sip-ip to autonat:xxx.xxx.xxx.xxx with xxx being our public IP which fixed internal calls/outbound calls but external calls inbound to the trunk still don't work.I've made sure the IP of the trunk is whitelisted from fail2ban as well.

What else could be the issue?
 
Last edited:

krishanodedra

New Member
Jul 17, 2018
28
0
1
31
Pastebin attached. It's not getting past the invite.

I masked the IP information
 

Attachments

  • d00fa3f9.txt
    3.1 KB · Views: 4

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,045
566
113
That either looks like th ip is already banned in fail2ban or the profile is not listening on 10.0.0.4.

Either that or you should be seeing traffic into freeswitch.
 

krishanodedra

New Member
Jul 17, 2018
28
0
1
31
That either looks like th ip is already banned in fail2ban or the profile is not listening on 10.0.0.4.

Either that or you should be seeing traffic into freeswitch.
Fail2ban looks fine I don't see the IP there and have whitelisted it as well. Where exactly would I check to see if the profile is listening on 10.0.0.4?
 

krishanodedra

New Member
Jul 17, 2018
28
0
1
31
In fs_cli:

Code:
sofia status profile external
freeswitch@HOSTNAME> sofia status profile external
=================================================================================================
Name external
Domain Name N/A
Auto-NAT true
DBName sofia_reg_external
Pres Hosts
Dialplan XML
Context public
Challenge Realm auto_to
RTP-IP 10.0.0.4
Ext-RTP-IP PUBLICIP
SIP-IP 10.0.0.4
Ext-SIP-IP PUBLICIP
URL sip:mod_sofia@10.0.0.4:5080
BIND-URL sip:mod_sofia@10.0.0.4:5080;transport=udp,tcp
HOLD-MUSIC local_stream://default
OUTBOUND-PROXY N/A
CODECS IN G7221@32000h,G7221@16000h,G722,PCMU,PCMA
CODECS OUT PCMU,PCMA
TEL-EVENT 101
DTMF-MODE rfc2833
CNG 13
SESSION-TO 0
MAX-DIALOG 0
NOMEDIA false
LATE-NEG false
PROXY-MEDIA false
ZRTP-PASSTHRU false
AGGRESSIVENAT false
CALLS-IN 0
FAILED-CALLS-IN 0
CALLS-OUT 0
FAILED-CALLS-OUT 0
REGISTRATIONS 0

freeswitch@HOSTNAME>
 

krishanodedra

New Member
Jul 17, 2018
28
0
1
31
OK so last night internal calling and calling out was working but now I am getting SIP/2.0 403 Forbidden on all calls. I had to restore the database to get it to work again. Do you know what could be causing this issue?
 

krishanodedra

New Member
Jul 17, 2018
28
0
1
31
Post a log of a call
2019/05/05 18:02:47.724511 136.52.100.23:57145 -> 10.0.0.4:5060
INVITE sip:210@domainname.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.106:57145;branch=z9hG4bK-524287-1---5e836e7ce028de32;rport;alias
Max-Forwards: 70
Contact: <sip:203@136.52.100.23:57145;rinstance=d4ee31434c0ae021>
To: <sip:210@domainname.com>
From: "Test"<sip:203@domainname.com>;tag=dd4ce869
Call-ID: YWFlOGI0ZTgxNWVmMWE1MGI4MmM4ZjNlMmYzN2Q5M2U
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, REFER, INFO, NOTIFY, OPTIONS, UPDATE, PRACK, MESSAGE, SUBSCRIBE
Content-Type: application/sdp
Supported: replaces, 100rel
User-Agent: Bria iOS release 3.9.7 stamp 38887.38893
Content-Length: 286

v=0
o=- 1557079366782724 1 IN IP4 192.168.1.106
s=Cpc session
c=IN IP4 192.168.1.106
t=0 0
m=audio 63228 RTP/AVP 120 9 0 8 101
a=rtpmap:120 opus/48000/2
a=fmtp:120 useinbandfec=1; usedtx=1; maxaveragebitrate=64000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

2019/05/05 18:02:47.725155 10.0.0.4:5060 -> 136.52.100.23:57145
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 192.168.1.106:57145;branch=z9hG4bK-524287-1---5e836e7ce028de32;rport=57145;alias;received=136.52.100.23
From: "Test" <sip:203@domainname.com>;tag=dd4ce869
To: <sip:210@domainname.com>;tag=vmtyg2UcaQ1cg
Call-ID: YWFlOGI0ZTgxNWVmMWE1MGI4MmM4ZjNlMmYzN2Q5M2U
CSeq: 1 INVITE
User-Agent: FreeSWITCH
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Length: 0


2019/05/05 18:02:48.225681 10.0.0.4:5060 -> 136.52.100.23:57145
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 192.168.1.106:57145;branch=z9hG4bK-524287-1---5e836e7ce028de32;rport=57145;alias;received=136.52.100.23
From: "Test" <sip:203@domainname.com>;tag=dd4ce869
To: <sip:210@domainname.com>;tag=vmtyg2UcaQ1cg
Call-ID: YWFlOGI0ZTgxNWVmMWE1MGI4MmM4ZjNlMmYzN2Q5M2U
CSeq: 1 INVITE
User-Agent: FreeSWITCH
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Length: 0


2019/05/05 18:02:49.226721 10.0.0.4:5060 -> 136.52.100.23:57145
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 192.168.1.106:57145;branch=z9hG4bK-524287-1---5e836e7ce028de32;rport=57145;alias;received=136.52.100.23
From: "Test" <sip:203@domainname.com>;tag=dd4ce869
To: <sip:210@domainname.com>;tag=vmtyg2UcaQ1cg
Call-ID: YWFlOGI0ZTgxNWVmMWE1MGI4MmM4ZjNlMmYzN2Q5M2U
CSeq: 1 INVITE
User-Agent: FreeSWITCH
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Length: 0


2019/05/05 18:02:49.742937 136.52.100.23:57145 -> 10.0.0.4:5060
ACK sip:210@domainname.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.106:57145;branch=z9hG4bK-524287-1---5e836e7ce028de32;rport;alias
Max-Forwards: 70
To: <sip:210@domainname.com>;tag=vmtyg2UcaQ1cg
From: "Test"<sip:203@domainname.com>;tag=dd4ce869
Call-ID: YWFlOGI0ZTgxNWVmMWE1MGI4MmM4ZjNlMmYzN2Q5M2U
CSeq: 1 ACK
Content-Length: 0


2019/05/05 18:02:49.742971 136.52.100.23:57145 -> 10.0.0.4:5060
ACK sip:210@domainname.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.106:57145;branch=z9hG4bK-524287-1---5e836e7ce028de32;rport;alias
Max-Forwards: 70
To: <sip:210@domainname.com>;tag=vmtyg2UcaQ1cg
From: "Test"<sip:203@domainname.com>;tag=dd4ce869
Call-ID: YWFlOGI0ZTgxNWVmMWE1MGI4MmM4ZjNlMmYzN2Q5M2U
CSeq: 1 ACK
Content-Length: 0


_____________________________


2019-05-05 18:05:55.142674 [NOTICE] switch_channel.c:1104 New Channel sofia/internal/203@domainname.com [fd155d8a-564d-4dad-8de6-ee4873df7bd8]
2019-05-05 18:05:55.142674 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/203@domainname.com) Running State Change CS_NEW (Cur 1 Tot 9)
2019-05-05 18:05:55.142674 [DEBUG] sofia.c:10092 sofia/internal/203@domainname.com receiving invite from 136.52.100.23:57145 version: 1.8.5 -6-31281a0bf1 64bit
2019-05-05 18:05:55.142674 [WARNING] sofia.c:10256 IP 136.52.100.23 Rejected by acl "domains"
2019-05-05 18:05:55.142674 [DEBUG] switch_core_state_machine.c:603 (sofia/internal/203@domainname.com) State NEW
2019-05-05 18:05:55.142674 [NOTICE] sofia.c:2411 Hangup sofia/internal/203@domainname.com [CS_NEW] [CALL_REJECTED]
2019-05-05 18:05:55.162675 [DEBUG] sofia.c:1529 Channel is already hungup.
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/203@domainname.com) Running State Change CS_HANGUP (Cur 1 Tot 9)
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:847 (sofia/internal/203@domainname.com) Callstate Change DOWN -> HANGUP
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:849 (sofia/internal/203@domainname.com) State HANGUP
2019-05-05 18:05:55.162675 [DEBUG] mod_sofia.c:449 Channel sofia/internal/203@domainname.com hanging up, cause: CALL_REJECTED
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:60 sofia/internal/203@domainname.com Standard HANGUP, cause: CALL_REJECTED
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:849 (sofia/internal/203@domainname.com) State HANGUP going to sleep
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:619 (sofia/internal/203@domainname.com) State Change CS_HANGUP -> CS_REPORTING
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:584 (sofia/internal/203@domainname.com) Running State Change CS_REPORTING (Cur 1 Tot 9)
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:935 (sofia/internal/203@domainname.com) State REPORTING
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:174 sofia/internal/203@domainname.com Standard REPORTING, cause: CALL_REJECTED
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:935 (sofia/internal/203@domainname.com) State REPORTING going to sleep
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:610 (sofia/internal/203@domainname.com) State Change CS_REPORTING -> CS_DESTROY
2019-05-05 18:05:55.162675 [DEBUG] switch_core_session.c:1715 Session 9 (sofia/internal/203@domainname.com) Locked, Waiting on external entities
2019-05-05 18:05:55.162675 [NOTICE] switch_core_session.c:1733 Session 9 (sofia/internal/203@domainname.com) Ended
2019-05-05 18:05:55.162675 [NOTICE] switch_core_session.c:1737 Close Channel sofia/internal/203@domainname.com [CS_DESTROY]
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:738 (sofia/internal/203@domainname.com) Running State Change CS_DESTROY (Cur 0 Tot 9)
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:748 (sofia/internal/203@domainname.com) State DESTROY
2019-05-05 18:05:55.162675 [DEBUG] mod_sofia.c:354 sofia/internal/203@domainname.com SOFIA DESTROY
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:181 sofia/internal/203@domainname.com Standard DESTROY
2019-05-05 18:05:55.162675 [DEBUG] switch_core_state_machine.c:748 (sofia/internal/203@domainname.com) State DESTROY going to sleep
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,045
566
113
You must have changed something in the sip profiles for this to happen.
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,045
566
113
In your internal sip profile what do you have auth-calls set to?
 

krishanodedra

New Member
Jul 17, 2018
28
0
1
31
In your internal sip profile what do you have auth-calls set to?
It is set to $${internal_auth_calls}

The only thing I changed in the SIP Profile was I set the internal SIP profile values for ext-rtp-ip & ext-sip-ip to be autonat:xxx.xxx.xxx.xxx with xxx being the public IP address of the PBX. The new server is hosted in Azure behind NAT.

I have since changed it back $${external_rtp_ip} & $${external_sip_ip} for testing but still the same issue.
 

krishanodedra

New Member
Jul 17, 2018
28
0
1
31
Hi All,

Ok so I setup the VM in Google Cloud and the same issue! I thought maybe it was my restore messing something up but I then tried a fresh install and same issue on the fresh install.

Google cloud doesn't do instance level public IP address so it's still going through NAT.

Is there anything else I need to do for NAT other than autonat:xxx.xxx.xxx.xxx?
 

krishanodedra

New Member
Jul 17, 2018
28
0
1
31
Yes it was 1.8.5 but we downgraded to 1.8.4.

Once we changed the SIP signaling from UDP to TCP from our trunk it fixed the issue. Also we had to edit the the ext_sip_ip and ext_rtp_ip under Advanced - Variables (not under the SIP profile) with the public IP address and that fixed the call forbidden issue on internal extensions.

I am working on a cluster is there a better variable here that we can use that will detect the external IP through NAT? Since we will be replicating the freeswitch database we need to find a variable that will work for both servers that have different public IP addresses.
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,045
566
113
Clustering doesn't work, not active/active anyway with multiple tenants.
 
Status
Not open for further replies.