Wow. How in the world can that ever work? Look at the trace. You are not sending the real IP address of sipx to the ITSP I believe. It will of course timeout because it can't route to you. Besides the domain name, did you alter the trace to make it unintelligible? If so, you need to clarify that or noone will be able to follow the trace.
On Mon, Jul 5, 2010 at 9:25 AM, [email protected] <[email protected]>wrote: > Sorry, i forgot to attach the trace. Here it is. > > On Mon, 2010-07-05 at 16:17 +0300, [email protected] wrote: > > Hi, > > > > before asking my questions i would like to explain our installation and > > network, so you can have a better idea what we have done and we are > > trying to do. > > > > We have one machine with 1 public ip address. We have installed on this > > machine openvpn server and also virtualbox. > > > > We created one virtual machine on vbox that have centos 5.5 installed > > and on it sipxecs. > > > > On host machine we create a tap0 interface and then we add tap0 to a > > bridge interface with ip 10.1.1.1. We create this bridge interface in > > order to give internet access to guest machine and to make visible guest > > from host machine. On guest machine we use one interface with ip > > 10.1.1.2. In order to give internet access to guest machine, we create > > nat on host machine. > > > > We follow this article for vbox networking: > > http://www.virtualbox.org/wiki/Advanced_Networking_Linux > > > > As you already know on host machine we have installed openvpn and it > > acts as vpn server. We have set openvpn to use tap device and to act as > > a bridge and openvpn has this configuration: > > > > port 1194 > > proto udp > > dev tap0 > > > > ca ca.crt > > cert server.crt > > key server.key > > dh dh1024.pem > > > > server-bridge 10.1.1.1 255.255.0.0 10.1.1.3 10.1.1.254 > > ifconfig-pool-persist ipp.txt > > client-to-client > > client-config-dir ccd > > > > keepalive 10 60 > > comp-lzo > > user nobody > > group nobody > > persist-key > > persist-tun > > status openvpn-status.log > > verb 3 > > > > When we try to register over vpn all is ok and our registratin urls > > looks this way: > > > > <sip:[email protected]:40200;x-sipX-nonat> > > > > Outgoing and incomming calls between sipx users is ok and internal > > communication is ok. At least it looks ok from our tests. > > > > Now we are trying to make sipxecs to be accessible also from non vpn > > users (remote users) and to be able to call via ITSP and to receive > > calls from ITSP. > > > > Registration from remote users also look ok. We are able to register and > > the url looks ok. > > > > Until this moment all is ok. The problem comes when we try to call out > > via ITSP. > > > > In logs i see that we register to ITSP without any problems, in sipx web > > interface also shows AUHTENTICATED. > > > > The problem appear when i try to make outgoing call via ITSP. Then on > > the phone i get "408 ITSP Time out". I checked the traces, but cannot > > figure out what the problem is. > > > > I was thinking that the problem maybe the rules that i use for > > forwarding the ports to sipx from public interface on host machine. But > > i'm not sure if this is the problem. > > > > I use these rules: > > > > IPTABLES=/sbin/iptables > > export EXTIF=eth0 > > export BRIF=br0 > > > > # my sipXecs proxy server and sipxbridge run here. > > export SIPXADDR=10.1.1.2 > > export PORTRANGE=30000:31000 > > > > > > #set a default policy > > /sbin/iptables -P INPUT ACCEPT > > /sbin/iptables -F INPUT > > /sbin/iptables -P OUTPUT ACCEPT > > /sbin/iptables -F OUTPUT > > /sbin/iptables -P FORWARD DROP > > /sbin/iptables -F FORWARD > > /sbin/iptables -t nat -F > > > > # set forwarding and nat rules > > /sbin/iptables -A FORWARD -i $EXTIF -o $BRIF -j ACCEPT > > /sbin/iptables -A FORWARD -i $BRIF -o $EXTIF -j ACCEPT > > > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p udp --dport 5060 -j > > DNAT --to-destination $SIPXADDR:5060 > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p udp --dport 5060 -j > > ACCEPT > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport 5060 -j > > DNAT --to-destination $SIPXADDR:5060 > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p tcp --dport 5060 -j > > ACCEPT > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p udp --dport 5070 -j > > DNAT --to-destination $SIPXADDR:5070 > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p udp --dport 5070 -j > > ACCEPT > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport 5070 -j > > DNAT --to-destination $SIPXADDR:5070 > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p tcp --dport 5070 -j > > ACCEPT > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p udp --dport 5080 -j > > DNAT --to-destination $SIPXADDR:5080 > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p udp --dport 5080 -j > > ACCEPT > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport 5080 -j > > DNAT --to-destination $SIPXADDR:5080 > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p tcp --dport 5080 -j > > ACCEPT > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p udp --dport 5090 -j > > DNAT --to-destination $SIPXADDR:5090 > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p udp --dport 5090 -j > > ACCEPT > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport 5090 -j > > DNAT --to-destination $SIPXADDR:5090 > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p tcp --dport 5090 -j > > ACCEPT > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport 9090 -j > > DNAT --to-destination $SIPXADDR:9090 > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p tcp --dport 9090 -j > > ACCEPT > > > > /sbin/iptables -t nat -A PREROUTING -i $EXTIF -p tcp --dport 81 -j DNAT > > --to-destination $SIPXADDR:8443 > > /sbin/iptables -A FORWARD -i $EXTIF -d $SIPXADDR -p tcp --dport 8443 -j > > ACCEPT > > > > /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE > > > > > > Are these rules above wrong? If yes, then what are the right rules that > > i need to use when sipxecs is located in private network behind NAT? > > > > I suppose there are a lot of people that have such/similar installations > > and i will be very happy if you share your experience in such > > installations. > > > > Is it possible something to be wrong in headers and this way ITSP does > > not know where to send packages? > > > > I attach one of the traces for failed outgoing call where i get ITSP > > Timeout error. > > > > Let me know if you need snapshot of sipx installation and i will send it > > too. > > > > What we need know is to get working outgoing and incoming calls via > > ITSP. > > > > P.S. we have installed sipxecs 4.2.0-018575. > > > > Thanks in advanced! > > > > > _______________________________________________ > 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/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
_______________________________________________ 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/
