multiple ip´s - 3cx using wrong ip for outgoing

[andy]

Hi

I had many problems with V5. It would simply not ring on phones behind NAT devises. Now I found out why!
My SIP server has 5 IP´s and it seems that V5 uses the last IP for outpound connections.
So if a SIP device behind NAT logges into the first IP the NAT device is of course not accepting connectins on that Port from the last IP of the server.

Is there a setting in the .ini file to manually set the server IP?
Or why is 3cx V5 using the last IP for outgoing and not the IP where the device registerd?

Thanks

 

[archie]

V5 uses all IPs for outgoing calls. It depends only on Windows routing table which exactly IP will be choosen in each case. Check your routing table by issuing 'route print' command.

 

[andy]

If V5 uses any IP of the 5 the server has how will SIP devices behind a NAT device receive calls?
NAT only works if the return packet (incomming packet) is from the same IP as the initial TCPIP request.
So if the SIP device (in my case internal extension 100) contacts/registers with the server sip.xxx.com (first IP of the server) than the initial call that extension must come from the servers first IP.

I tried the following: register internal extension 100 with the servers Last IP and everything works just fine.
If I register extension 100 to the first IP of the server no incomming calls to that extension are possible.

That has nothing to do with a routing thing on ther server but simply with 3CX V5 not using the correct IP.

The log also don´t show that it is using the last IP to connect out (as source) I only found out by looking into the firewall logs.

 

[andy]

the clear it up a little more

Servers IP´s

213.229.2.121 (knoflach.com)
213.229.2.122
213.229.2.123
213.229.2.124
213.229.2.125

So my SIP devices behind NAT connect to "knoflach.com" (first IP)
extensions 100,200
When now someone calls extensions 100 (that is behind NAT) 3cx V5 uses the LAST (213.229.2.125) IP to make the call to extension 100 that fails because NAT table on NAT router has the first IP in table!

 

[archie]

The log also don´t show that it is using the last IP to connect out (as source) I only found out by looking into the firewall logs.

This also proves that your window's routing is set in that way that last IP has most precendence (priority). So, it even doesn't matter from which interface 3CX is sending - anyway windows will send it from the NIC with lowest metrics.

 

[andy]

the metric is set to 1 fir this interface
all outgoing traffic from my serveruses the first IP.
Why should just 3cx v5 be different and windows uses the last ip? This does not make sense.
Please ajust/correct the 3cx v5 software
Thanks

PS: this is the route print:

Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 213.229.2.126 213.229.2.121 1
213.229.2.120 255.255.255.248 213.229.2.121 213.229.2.121 1
213.229.2.121 255.255.255.255 127.0.0.1 127.0.0.1 1
213.229.2.122 255.255.255.255 127.0.0.1 127.0.0.1 1
213.229.2.123 255.255.255.255 127.0.0.1 127.0.0.1 1
213.229.2.124 255.255.255.255 127.0.0.1 127.0.0.1 1
213.229.2.125 255.255.255.255 127.0.0.1 127.0.0.1 1
213.229.2.255 255.255.255.255 213.229.2.121 213.229.2.121 1
255.255.255.255 255.255.255.255 213.229.2.121 213.229.2.121 1
Default Gateway: 213.229.2.126

 

[andy]

i have to add that on the server are running multiple other applications /server software and this are all using the 1st IP for outgoing traffic. No other software uses the last IP. only 3cx v5 ?!

 

[andy]

I now tried on a second server with also more IP´s and 3cx V5 also uses the last IP for outgoing connections to my internal SIP devices.

route:

Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 217.196.80.81 217.196.80.82 20
217.196.80.0 255.255.255.0 217.196.80.82 217.196.80.82 20
217.196.80.82 255.255.255.255 127.0.0.1 127.0.0.1 20
217.196.80.83 255.255.255.255 127.0.0.1 127.0.0.1 20
217.196.80.84 255.255.255.255 127.0.0.1 127.0.0.1 20
217.196.80.85 255.255.255.255 127.0.0.1 127.0.0.1 20
217.196.80.86 255.255.255.255 127.0.0.1 127.0.0.1 20
217.196.80.255 255.255.255.255 217.196.80.82 217.196.80.82 20
255.255.255.255 255.255.255.255 217.196.80.82 217.196.80.82 1
Default Gateway: 217.196.80.81

 

[andy]

this is from the startup log from 3cx v5

11:29:13.545 StunClient:rocess :[CM506002]: Resolved SIP external IPort (213.229.2.122:5060) on Transport 213.229.2.122:5060
11:29:13.545 StunClient:rocess :[CM506002]: Resolved SIP external IPort (213.229.2.123:5060) on Transport 213.229.2.123:5060
11:29:13.545 StunClient:nAddTransport :[CM506001]: STUN request to resolve SIP external IPort mapping is sent to STUN server 217.196.80.82:3478 over Transport 213.229.2.122:5060
11:29:13.545 StunClient:rocess :[CM506002]: Resolved SIP external IPort (213.229.2.124:5060) on Transport 213.229.2.124:5060
11:29:13.535 StunClient:nAddTransport :[CM506001]: STUN request to resolve SIP external IPort mapping is sent to STUN server 217.196.80.82:3478 over Transport 213.229.2.123:5060
11:29:13.535 StunClient:rocess :[CM506002]: Resolved SIP external IPort (213.229.2.125:5060) on Transport 213.229.2.125:5060
11:29:13.535 StunClient:nAddTransport :[CM506001]: STUN request to resolve SIP external IPort mapping is sent to STUN server 217.196.80.82:3478 over Transport 213.229.2.124:5060
11:29:13.535 StunClient:nAddTransport :[CM506001]: STUN request to resolve SIP external IPort mapping is sent to STUN server 217.196.80.82:3478 over Transport 213.229.2.125:5060
11:29:13.425 CallMgr:nAddIPs :IP(s) added:[213.229.2.121,213.229.2.125,213.229.2.124,213.229.2.123,213.229.2.122]
11:29:08.608 StunClient:rocess :[CM506002]: Resolved SIP external IPort (213.229.2.121:5060) on Transport 213.229.2.121:5060
11:29:08.598 StunClient:nInitTests :[CM506001]: STUN request to resolve SIP external IPort mapping is sent to STUN server 217.196.80.82:3478 over Transport 213.229.2.121:5060
11:29:05.683 DBA :[CM501003]: Connected: Database
11:29:04.852 CallMgr::findLocalIPs :[CM501006]: Default Local IP address: [213.229.2.121]
11:29:03.350 CallCtrl::thread :[CM501007]: *** Started Calls Controller thread ***

 

[archie]

Sorry, I do not understand what is the problem? It seems all your IPs has been properly resolved and are used as external. Doesn't your system work? All IPs has equal metrics, so it doesn't matter which one will be chosen for outbound calls. If you want some specific IP to be used - make lower metric (higher priority) for it.

 

[andy]

the problem is that the SIP devices (extension 100,200) are behind a NAT device and register to the first IP of the server.
So the NAT table of the router in front of the extension 100+200 only allows incomming fromt the first ip of the server where the initial TCPIP session is open.
If the server now connects to extension 100+200 and uses a other source IP (in my case the 5th IP) the NAT router will block this incomming connection.

I cane maybe explane more in detail if I could call some kind of support line to explain?! (I´m in Austria)

 

[andy]

also in windows you can only set METRIC on a per interface basis and not on virtual IP´s per interface.
1 have only 1 interface with 5 IP´s and therefore they have the same metric!

 

[archie]

Are you sure your phones use TCP/IP connection? Actually, they usually use UDP (connectionless). And, if TCP is in use, than PBX keeps connection open until registration is valid, so it couldn't be blocked by NAT. Again, if PBX sees incoming registration (on UDP), it stores a transport (IP) from which it has arrived, and than uses it for every outgoing message. So, to answer all your questions (and probably find our bug if something doesn't work as I described above), we would appreciate if you can take Wireshark (or Ethereal) capture of registration and outgoing call to that extension, and send it to us to analyze.
My e-mail is arthur at 3cx dot com.

 

[archie]

Also, it may shed some light on issue, if you set verbose logging, restart your system, wait until extension is registered and than make a call. After that zip 3CXPhoneSystem.trace.log file and send it to me: arthur at 3cx dot com.