> First, a little topology: > > Our sipXecs server is on a DMZ with the address > 192.168.9.1/24. The firewall address on that DMZ (which is > also the default route for the sipXecs server) is 192.168.9.254. > > We have a workstation on the firewall's protected network > with the address 192.111.31.44/24 (we got an address > allocation from IANA years ago before NAT was widespread.) > > Now the problem: > We were using X-Lite on this workstation for a month or so, > and decided to upgrade to eyeBeam for the extra features. > When we try to place an outbound call with eyeBeam, the > firewall reboots (which means that there is a problem with > the firewall, since nothing should cause it to reboot, but > that's another topic.)
Reboots?! Yikes. If you go back to the old version of x-lite do things go back to normal? > > I did a Wireshark capture, and I saw that after eyeBeam sends > the REGISTER, sipXecs sends a SUBSCRIBE back to the > workstation that makes a couple references to 192.168.9.254. > > Later, in addition to sending a subscribe to the sipXecs > server, eyeBeam sends a larger number of subscribe requests > to the firewall address (192.168.9.254) 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? > > Am I correct that something (eyeBeam, Firewall, and/or > sipXecs) is doing something wrong here? If so, is this a > problem with the way that the firewall is applying NAT, a > problem with how sipXecs is dealing with NAT, or some other > issue? Is the SUBSCRIBE that sipXecs sent back to the > workstation responsible for eyeBeam's attempts to send > SUBSCRIBES to the firewall address? > > > 0000 00 16 35 a2 f8 22 00 90 fb 0d c0 fc 08 00 45 00 ..5..".. ......E. [...insert mess here...] ... > 0550 3a 35 36 37 36 34 3b 74 72 61 6e 73 70 6f 72 74 :56764;t ransport 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. _______________________________________________ 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/
