[CM305004]: Failed to find a transport to host

Discussion in '3CX Phone System - General' started by matthijsolislagers, Jan 22, 2008.

Thread Status:
Not open for further replies.
  1. matthijsolislagers

    matthijsolislagers New Member

    Joined:
    Jan 22, 2008
    Messages:
    140
    Likes Received:
    0
    Hi,

    I'm running 3CX build 5.0.3790.0 on a Windows server 2003 SBS. The server is multihomed with one external nic and one internal nic. The external nic has a external ip.

    When I'm trying to register with XeloQ I get the following message in my server log:

    14:45:59.017 DeviceRecord::DeviceRecord [CM305004]: Failed to find a transport to host 81.26.212.150

    I tried to remove the stun server but it didn't work.

    The server log show's both IP's:

    14:39:55.249 CallMgr::eek:nAddIPs IP(s) added:[10.0.0.1,xxx.xxx.31.238]
    14:39:45.921 CallMgr::findLocalIPs [CM501006]: Default Local IP address: [10.0.0.1, xxx.xxx.31.238]

    Can someone please help me? I'm stuck..

    I'm planning to buy the Small business version when this works.
     
  2. matthijsolislagers

    matthijsolislagers New Member

    Joined:
    Jan 22, 2008
    Messages:
    140
    Likes Received:
    0
    OK. After a lot of reboots, sleepless nights, reading logs I figured something out.

    I noticed that after a random time the line does register successful. After a reboot the same issue began.

    Here's wat I've figured out:

    1) The server has 2 nic's: First: Internal (ip: 10.0.0.1) Second: External (ip: xx.xx.31.238)
    2) The server is also a VPN server (routing and remote access)
    3) When I reboot the server the log is as following:

    15:30:47.027 DeviceRecord::DeviceRecord [CM305004]: Failed to find a transport to host 194.221.62.198
    15:30:46.996 IVRConnected [CM501004]: Connected: IVR Service
    15:30:46.980 MediaServerConnected [CM112000] Media Server is connected
    15:30:46.855 DBA [CM501003]: Connected: Database
    15:30:46.777 CallMgr::findLocalIPs [CM501006]: Default Local IP address: [10.0.0.1, xx.xxx.31.238]
    15:30:46.621 CallCtrl::thread [CM501007]: *** Started Calls Controller thread ***
    15:30:46.621 CallMgr::Initialize [CM501002]: Version: 5.0.3790.0
    15:30:46.621 CallMgr::Initialize [CM501001]: Start 3CX PhoneSystem Call Manager
    15:30:46.621 LoadLicenceInfo [CM501010]: License Info: Load Failed

    4) When a random home worker connects a VPN tunnel to the server the following log entry's show up:

    15:34:09.648 ClientRegs::eek:nSuccess [CM504004]: Registration succeeded for: 10000@Voipbuster
    15:34:09.289 ClientRegs::Register [CM504003]: Sent registration request for 10000@Voipbuster
    15:34:08.023 StunClient::process [CM506002]: Resolved SIP external IP:port (xx.xxx.31.238:64285) on Transport 10.0.0.106:5060
    15:34:07.851 StunClient::eek:nAddTransport [CM506001]: STUN request to resolve SIP external IP:port mapping is sent to STUN server 64.69.76.23:3478 over Transport 10.0.0.106:5060
    15:34:07.726 CallMgr::eek:nAddIPs IP(s) added:[10.0.0.106]

    5) So, it seems the random time is actually not random. It is a random VPN worker.

    Now the strange thing is.. Transport 10.0.0.106 is actually a virtual ip. Created by routing and remote access for VPN purposes. There is no gateway or internet connectivity possible via that ip. So to me it seems like a bug in 3CX. The only way to the internet is through the external nic. 3CX doesn't try that.

    Can anyone confirm this? Has someone got a solution for this?

    Thank you!
     
  3. matthijsolislagers

    matthijsolislagers New Member

    Joined:
    Jan 22, 2008
    Messages:
    140
    Likes Received:
    0
    Maybe a feature in 3CX to select the external nic is a solution for this problem. I notices more users having the same problem.
     
  4. matthijsolislagers

    matthijsolislagers New Member

    Joined:
    Jan 22, 2008
    Messages:
    140
    Likes Received:
    0
    Does someone have the same problem as I do?
     
  5. Nick Galea

    Nick Galea Site Admin

    Joined:
    Jun 6, 2006
    Messages:
    1,948
    Likes Received:
    254
    So reading your topic - a new connection by a VPN worker registers a new IP on the system (that of the remote VPN worker) and this causes registrations to go via the VPN connection which fails?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. matthijsolislagers

    matthijsolislagers New Member

    Joined:
    Jan 22, 2008
    Messages:
    140
    Likes Received:
    0
    No, not really.

    Before the VPN worker log's in the 3CX server notices 2 IP's as you can see in the log: 1 internal and 1 external. At this point 3CX is unable to register with the VOIP providers and is unable to contact STUN.

    After a VPN log's in another IP is noticed by 3CX. The local endpoint IP of the VPN (the gateway IP for the VPN home user). How this exactly works I don't know, but this is the way Routing and Remote Access works. I don't think the registration goes via the VPN tunnel. I can see the connection go via the external IP when I monitor it. 3CX just thinks it does..

    So my problem is. After a reboot 3CX doesn't register with the VOIP providers until a VPN home worker connects to the server.

    I hope this is clear enough for you. If you need any more information just let me know.

    Thanks
     
  7. matthijsolislagers

    matthijsolislagers New Member

    Joined:
    Jan 22, 2008
    Messages:
    140
    Likes Received:
    0
    For your information, this is my routing table:

    Image no longer available
     
  8. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    matthijsolislagers,

    Please find [Network] section in 3CXPhoneSystem.ini file and add value(or modify it if exists) localSubnets=0.0.0.0/0

    [Network]
    localSubnets=0.0.0.0/0
    ....

    then restart PBX.

    It should resolve this problems.
    Please send me confirmation(or confutation) to private, or "stepan" email box.

    Thanks
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.