SBC on Debian get disconnected

[Victor Camacho]

Hi,
I am having problems connecting my 3CXSBC to a pbxexpress in Azure.
Here is my conf and error. I have rechecked all my settings but I get disconnected.
I see the connections leaving my office to the Azure ip address.
Names have been changed to protect the innocent.
xxx.xxx.xxx.200 azure static ip
xxx.xxx.xxx.99 internal private ip of SBC
Thanks in advance for any help or clues.

3cxsbc.conf
[General]
ReconnectInterval = 30 # seconds
PrintStatsInterval = 30 # seconds
FailoverInterval = 90 # seconds

[Log]
Type = syslog # cout, cerr, syslog
Level = NONE # NONE", "EMERG", "ALERT", "CRIT", "ERR", "WARNING", "NOTICE", "INFO", "DEBUG", "STACK", "CERR", "VERBOSE"
#Level = VERBOSE # NONE", "EMERG", "ALERT", "CRIT", "ERR", "WARNING", "NOTICE", "INFO", "DEBUG", "STACK", "CERR", "VERBOSE"

[Bridge/123456]
#Mandatory
ID = 123456
Password = BLOCKED

TunnelAddr =HOSTNAME.3cx.us # 3CX Phone System Tunnel TCP IP or FQDN
TunnelPort = 5090 # 3CX Phone System Tunnel Port

#TunnelAddr2 = # 3CX Phone System Failover Passive Tunnel IP or FQDN
#TunnelPort2 = # 3CX Phone System Failover Passive Tunnel Port

#Optional
Name = "3CX Session Border Controller"

PbxSipIP =xxx.xxx.xxx.200 # IP address of PBX, mandatory for provisioning to work
PbxSipPort =5060 # SIP port of PBX, mandatory for provisioning to work

#LocalSipAddr = 0.0.0.0 # local SIP (UDP/TCP) address (def: 0.0.0.0) binds on all interfaces
LocalSipAddr = xxx.xxx.xxx.99 # local SIP (UDP/TCP) address (def: 0.0.0.0) binds on all interfaces
#LocalSipPort = 5060 # local SIP (UDP/TCP) address (def: 5060) Must be 5060
LocalSipPort = 5060 # local SIP (UDP/TCP) address (def: 5060) Must be 5060

#SecurityMode = 1
SecurityMode = 0


Portion of repeating error log.
debug:3CXTunnel[378]::2019-01-14T12:57:36.642095-06:00: TUNL | 140629054478528 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:241 | Making TCP connection to [ V4 xxx.xxx.xxx.200:5090 TCP ]
debug:3CXTunnel[378]::2019-01-14T12:57:36.642638-06:00: TUNL | 140629054478528 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:458 | FdSet timeout = 1000
debug:3CXTunnel[378]::2019-01-14T12:57:36.656955-06:00: TUNL | 140629054478528 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/security.cpp:1114 | Ready to send, send q size = 0
debug:3CXTunnel[378]::2019-01-14T12:57:36.657548-06:00: TUNL | 140629054478528 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:616 | Tunnel connection to [ V4 xxx.xxx.xxx.200:5090 TCP ] is accepted
debug:3CXTunnel[378]::2019-01-14T12:57:36.658092-06:00: TUNL | 140629054478528 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:667 | Sending first packet from [ V4 0.0.0.0:32983 UNKNOWN_TRANSPORT ] to [ V4 xxx.xxx.xxx.200:5090 TCP ]
debug:3CXTunnel[378]::2019-01-14T12:57:36.658641-06:00: TUNL | 140629054478528 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:458 | FdSet timeout = 1000
info:3CXTunnel[378]::2019-01-14T12:57:36.680759-06:00: TUNL | 140629054478528 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/security.cpp:1342 | Keep-alive received
warning:3CXTunnel[378]::2019-01-14T12:57:36.681335-06:00: TUNL | 140629054478528 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:638 | Tunnel connection to [ V4 xxx.xxx.xxx.200:5090 TCP ] is disconnected; error: Connection is terminated by peer - while begin to read a packet from tunnel
err:3CXTunnel[378]::2019-01-14T12:57:36.681878-06:00: TUNL | 140629054478528 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:268 | Bridge [3CX Session Border Controller] failure 'Connection is terminated by peer - while begin to read a packet from tunnel' on TCP connection: TunnelTcp:rocess
debug:3CXTunnel[378]::2019-01-14T12:57:36.682419-06:00: TUNL | 140629054478528 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:581 | === Statistics:#012 Keep-alives: recv 1, sent 0#012 Transfers: recv last 0 ms ago,#011total 8 bytes#012 sent last 24 ms ago,#011total 67 bytes#012===
warning:3CXTunnel[378]::2019-01-14T12:57:36.682963-06:00: TUNL | 140629054478528 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/Bridge.cpp:261 | Tunnel disconnected. Terminating all active calls.
debug:3CXTunnel[378]::2019-01-14T12:57:37.681730-06:00: TUNL | 140629054478528 | /home/repomaster/workspace/SBC/Sources/Projects/3CXSBC/TunnelTcp.cpp:581 | === Statistics:#012 Keep-alives: recv 0, sent 0#012 Transfers: recv last 1001 ms ago,#011total 0 bytes#012 sent last 1025 ms ago,#011total 0 bytes#012===

 

[eddv123]

Connection is terminated by peer

Well from the logs the connection is being dropped from the remote connection. I am assuming of course that the logging has been taken from the tunnel logs on the 3CX side ?

I would firstly (as a test) confirm that the 3CX firewall checker is passing. Failing that I think gathering the logging this can be done in the 3cxsbc.conf which you have posted above.

Change the DEBUG to VERBOSE then run the below commands:

1) Edit file /etc/3cxsbc.config and uncomment the # File section.
2) Stop the 3cxsbc service (service 3cxsbc stop)
3) Stop the rsyslog service (service rsyslog stop)
4) Delete file ls -l /var/log/ (rm /var/log/3cxsbc.log)
5) Recreate /var/log/3cxsbc.log (touch /var/log/3cxsbc.log)
6) Start the rsyslog service (service rsyslog start)
7) Start the 3cxsbc service (service 3cxsbc start

You can tail -f the logs so that it saves to a txt file. Run the error and see if it reports anything.

 

[eddv123]

Perhaps also check your Debian IP tables, although if it were a firewall/IP table issue at either end I would expect it to be a complete block (unless of course it was SIP ALG related perhaps): https://www.3cx.com/docs/manual/firewall-router-configuration/

 

[Lee Cramman]

I don't bother troubleshooting an SBC without trying a rebuild first - it's such an easy / quick thing to do.

I have noticed a definite difference in the reliability of an SBC that is configured using the installer (rock solid) versus ones where the .conf file was edited by hand (often gives me problems), although that might just be my ham-fistedness with vi / nano...

 

[Victor Camacho]

Well from the logs the connection is being dropped from the remote connection. I am assuming of course that the logging has been taken from the tunnel logs on the 3CX side ?

Hi Eddv,
No, these are the logs from SBC side. Sorry for any confusion. The logs were run with the verbose setting. I will try on the 3CX side. Thanks for the help.

Also, my firewall is passing and showing the connection from the SBC to the 3CX vm.
I also have found that the 3CX vm netstat is showing the connection coming in to the vm.
I will try the logs on the server.

I don't bother troubleshooting an SBC without trying a rebuild first - it's such an easy / quick thing to do.

Hi Lee,
I may try this, plenty of old pcs sitting around.
The conf was originally done by the system. When I make a change, I will copy the original and comment it out and change the copy. I too have had to just quit a file because I hit the wrong key in vi.
Thanks for the idea.

ALSO - My understanding was the use of the SIP ports is all done through the tunnel?
All SIP traffic at this site is blocked by AT&T and I am trying to get around this until the block is lifted.
If any SIP traffic is not using the SBC then I will have to switch to VPN.
Please correct me if I am wrong about the SBC tunnel.
Thanks!

 

[YiannisH_3CX]

You are correct, all traffic between the SBC and the PBX is going through the tunnel (usually port 5090). Provisioning is done through Https

 

[Wendelspanswick]

We tend to use the server IP rather than the server FQDN in the SBC config and have found we get less drop outs.

 

[Victor Camacho]

Eddv123 mentioned logs on the 3CX to see what is happening there.
Which log would show this information or do I need to do a packet capture?
Thanks !!

You are correct, all traffic between the SBC and the PBX is going through the tunnel (usually port 5090). Provisioning is done through Https

Hi YiannisH_3CX
Thanks for the confirmation.

We tend to use the server IP rather than the server FQDN in the SBC config and have found we get less drop outs

Thanks Wendel,
The SBC log shows the resolution of the FQDN but I will test any way. One never knows.