> -----Original Message----- > From: Burden, Mike [mailto:[email protected]] > Sent: Thursday, February 11, 2010 12:52 PM > To: Joly, Robert AVAYA (CAR:9D30); [email protected] > Subject: RE: [sipx-users] Weird eyeBeam / NAT issue > > > Reboots?! Yikes. If you go back to the old version of x-lite do > things > > go back to normal? > > Yes, it does. The really bizarre part is that Counterpath says that > both are based on the same codestack. It's possible that > there's something that's correct in my X-Lite config that's > wrong in my eyeBeam config... I'm double-checking that.
Working out the config diffs (if any) between the two is a good starting place. > > I need to be clear on the topology because what you explain > does not > > exactly jive with the 'trace' you provided. Can 192.168.9.1 be > reached > > from 192.111.31.44? I.e. it I execute 'ping 192.168.9.1' on > > 192.111.31.44, will it work? > > The workstation (192.111.31.44) can ping the "private" IP > address of the sipXecs server (192.168.9.1), but the sipXecs > server cannot "see" the private IP address of the workstation > (traffic from the workstation > "looks" like it comes from the firewall address -- > 192.168.9.254). The > firewall will create a "virtual crack" to allow the sipXecs > server to reply to packets sent by the workstation. Got it, thanks. > > > Looking at this packet, it seems that your router is > performing a NAT > > function on packets from 192.11.31.44 to 192.168.9.1. More > > specifically, a SIP packet sent from 192.11.31.44 to > 192.168.9.1 will > be > > handled by your firewall's NAT function and the source IP > address for > > that packet will be changed from 192.11.31.44 to > 192.168.9.254. I was > > not expecting a NAT function to be turned on in the Protected > > Network->DMZ direction (but I expect it in the other direction). > > > > To me, this looks like a misconfiguration on the router but > then again > > I'm no DMZ authority :) Having said that, despite that potential > > misconfiguration, things such just chug along but they are not. I > would > > definitely start by looking at the NAT configuration and make sure > that > > you do not having 'looping NAT rules' (i.e. A maps to B, B > maps to A). > > If that does not resovle the issue, you'll have to post more > > comprehensive logs/traces. > > Workstations need to initiate communications with servers. Servers > usually don't need to initiate communication with workstations. > From innermost to outermost, the network is: Protected > (Workstations) > <--> DMZ (Internet Servers) <--> Public (Internet). NAT is applied > outbound. > > Our firewall's interface either applies NAT for a given pair > of hosts or doesn't... there is no way in this interface to > apply a 2nd (or 3rd or > 4th) NAT to any packet. > > > > My gut feeling at the moment is that sipXecs handles NAT > between itself and the ITSP fine, but it doesn't expect NAT > between itself and the phones. > I'm going to run a sipXtrace, but I suspect that it may be > necessary to disable NAT between the workstation and the > sipXecs server. Normally you shouln't need to do that. The remote worker NAT traversal feature in sipXecs is built to work in your configuration. Something else is brewing here. Plaase send me the sipXtrace when you get it and make sure it covers the phone's registration. Also, just to be clear, your Eyebeam is connecting to siPXecs's port 5060 (and not 5080), right? _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
