> 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. > 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. > 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. _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org 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/
