Thanks for your answers and fast reply, Tony.

Sorry for the trace, yes i altered it to mask some sensitive information
from trace. I will be more careful for the next time and will follow
your advice for clarifying. Sorry again :)

I was thinking that not sending the public ip address might be the
reason for all these problems.

How do i need to proceed, is this a sipxecs configuration problem or it
is because incomplete firewall rules as you commented already in your
previous post?

On Mon, 2010-07-05 at 09:31 -0400, Tony Graziano wrote:
> 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, an...@iguanait.com
> <an...@iguanait.com> wrote:
>         Sorry, i forgot to attach the trace. Here it is.
>         
>         
>         On Mon, 2010-07-05 at 16:17 +0300, an...@iguanait.com 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:7...@10.1.2.3: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 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/
> 
> 
> 
> -- 
> ======================
> Tony Graziano, Manager
> Telephone: 434.984.8430
> sip: tgrazi...@voice.myitdepartment.net
> Fax: 434.984.8431
> 
> Email: tgrazi...@myitdepartment.net
> 
> LAN/Telephony/Security and Control Systems Helpdesk:
> Telephone: 434.984.8426
> sip: helpd...@voice.myitdepartment.net
> 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 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/

Reply via email to