Two NIC server

[alit]

Have read various entries on this across the forum but cannot find an straight answer. Maybe I have missed something.

I have an HP Proliant DL360 G6 running SBS 2008. All fine. 3CX v8 was running on an old Dell box with a single NIC. Thats been fine as well. Created a backup of the config on the Dell and restored this to the HP box making sure the installer I used for 3CX was identical.

Dell IP address I created on the 2nd NIC on the HP. Created my routing table to point all requests for the SIP trunk to point at the correct router. Only one G/W is featured on one NIC. The other has none. In the "wrong" router I have put a route sending traffic to the SIP router. Proved all this to work with trace & ping tests.

Disconnected Dell & started 3CX on HP. SIP trunks register & outbound calls no problem. Nightservice routes inbound calls to voicemail. This works no problem. Day service - inbound calls fail. Looks show that the call routing is trying to present a call to the ring group from the wrong NIC IP. Clearly this is why they are failing.

Have ensured the STUN server is off & that I have enetred the ISP IP & the correct NIC selected. Ensured that in the "advanced" tab all the IPs relevent are correct. Not sure now what else to check? I have rolled back my config to the Dell so service is working. I am guessing therer is an answer to this judging by posts on here. Any ideas? Thanks!

 

[nwhitfield]

I found some weirdness with calls ging via the wrong NIC when I enabled the second one on my Windows XP box.

Everything worked fine with one NIC (which has a public IP), but I wanted a couple of phones on the private side of the network, which is behind an old Airport Extreme router that's not SIP-friendly. So, I thought I'd just connect the second NIC to that network.

Whenever I did, outbound calls stopped working in my case. Watching things with WireShark showed that, rather than going via the NIC with a public IP, calls to the SIP trunk went via the other NIC, through the Airport and then to the provider, bearing the originating IP of the Airport, rather than the one of the 3CX box, and so failing their IP-based authentication.

The problem wasn't a 3CX setting. It was Windows (and perhaps routed in the enumeration of NICs; I didn't experimentt to verify that).

I fixed it (XP Pro) by going to Control Panel, Network Connections.
Right click on the NIC that the traffic should be going through, select Properties
Select TCP/IP, then click Properties
On the TCP/IP Properties screen, click the Advanced button at the bottom
On the following screen ('Advanced TCP/IP settings') untick the 'Automatic metric' box and set 'Interface metric' to 1.

OK all the way out of this.

That fixed the problem for me; the hint that took me in that direction (besides Wireshark) was the routing table; pop open a command window and type

route print

and see what's listed as the Default Gateway; if it's not the address of the router that you expect the traffic to be heading towards, then the steps I outlined will probably fix things.

 

[broesder]

Hi,

I had the same problem, fixed it:

On the NIC settings of the private NIC, fill in ONLY the private IP and subnet, no default proxys and so on. So 3CX can't connect to the internet by the private NIC and will connect to the internet only by the public NIC. Phones connected to the private NIC will work fine.

Regards