In the diagram I sent you it explained how NAT needs to same port in both directions in order to properly function.
A call trace and viewing it in sipviewer will tell you if the port is identical on both legs of the call. If not, its an iptables issue. ============================ Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ ----- Original Message ----- From: [email protected] <[email protected]> To: Tony Graziano <[email protected]> Cc: [email protected] <[email protected]> Sent: Tue Jul 06 10:09:27 2010 Subject: Re: [sipx-users] Sipxecs behind NAT, firewall rules and ITSP Time out problem on outgoing calls. Hi, Tony. I really appreciate you help and your support in sipx. I found the problem. The problem was that in ITSP trunk settings this option was checked: "User part of INVITE SIP URI is a phone number". As i see this is checked by default and i didn't realized previously that this can be the problem. I saw this setting for first time today and disabling this option solved my ITSP Time out problem. Now when i call, the phone rings :) Now as you expected we have problem with audio :) We have one way audio. The sipxecs user (lets say extension 400 ) call to 8833495466, then phone rings. When it is picked up, user with extension 400 have audio, he hear the other side on the line. But the guy on 8833495466 does not hear anything and audio is missing. Anyway we moved with one step solving the ITSP time out problem :) Now we should deal with the one way audio. On Mon, 2010-07-05 at 14:31 -0400, Tony Graziano wrote: > Can your ITSP confirm they are seeing the invite from you? If so, what > do they see is wrong with it? > > > A lot of ITSP's require a certain number format, so check the invite > to make sure you sent it in the format they want it. Seriously, if > that were the problem though, they would send you back a meaningful > code. I wouldn't bang my head against the wall too long. until you get > to the point where the ITSP tells you what they don't like it would be > impractical to tell if the iptables filters are right now or not. > > > The fact the the entire transaction lasts less than 2 seconds and > "times out" in that period is a little bothersome, since "assuming" > the call went to the right IP/port at the ITSP. It could be that the > firewall is preventing any communication, but I doubt it based on your > table. This is one reason I like pfsense as a firewall, it has > wireshark capture built in for just such an occasion. > > > What does your ITSP say about the call? Can you log rejected traffic > and see if it hits your firewall log? > > > > > > > On Mon, Jul 5, 2010 at 12:04 PM, [email protected] > <[email protected]> wrote: > Thanks for the useful information and the link you posted. The > information you provided was useful to me to understand how go > the > communication between sipx and ITSP when there is call and > also > registration process. > > This is interesting about port 5080. I have not changed > default ports. > > I didn't see on frame 14 that we are sending call to 5080. In > frame 13 i > see that the route and destination are set with ITSP ip > address and port > 5060. It looks to me that we actually send the requests to > 5060 and from > what you wrote in your previous posts this is the correct > port. Am i > wrong? > > Yes you are right in headers appeared sipxecs private address > i tried to > fix this problem doing this: > > I did following changes on sipx: > > System -> Internet Calling -> NAT -> Server behind NAT > (checked) > System -> Servers -> sipx.mydomain.net -> NAT -> Public IP > address (here > i set the public IP address - 87.1xx.xxx.43). > > > Are these settings correct and is this the right way they to > be > configured? If not, what are the correct settings that i have > to change? > > I fixed also firewall rules and now my firewall rules looks > this way: > > Table: nat > Chain PREROUTING (policy ACCEPT) > num target prot opt source destination > > 1 DNAT udp -- 0.0.0.0/0 87.1xx.xxx.43 > udp > dpt:5060 to:10.1.1.2 > 2 DNAT tcp -- 0.0.0.0/0 87.1xx.xxx.43 > tcp > dpt:5060 to:10.1.1.2:5060 > 3 DNAT udp -- 0.0.0.0/0 87.1xx.xxx.43 > udp > dpt:5080 to:10.1.1.2:5080 > 4 DNAT udp -- 0.0.0.0/0 87.1xx.xxx.43 > udp > dpts:30000:31000 to:10.1.1.2 > 5 DNAT tcp -- 0.0.0.0/0 87.1xx.xxx.43 > tcp > dpt:81 to:10.1.1.2:8443 > > Chain POSTROUTING (policy ACCEPT) > num target prot opt source destination > 1 MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 > > Chain OUTPUT (policy ACCEPT) > num target prot opt source destination > > Table: filter > Chain INPUT (policy ACCEPT) > num target prot opt source destination > > 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 > state > RELATED,ESTABLISHED > > Chain FORWARD (policy DROP) > num target prot opt source destination > > 1 ACCEPT tcp -- 0.0.0.0/0 10.1.1.2 > state > NEW tcp dpt:5060 > 2 ACCEPT udp -- 0.0.0.0/0 10.1.1.2 > udp > dpt:5060 > 3 ACCEPT udp -- 0.0.0.0/0 10.1.1.2 > udp > dpt:5070 > 4 ACCEPT udp -- 0.0.0.0/0 10.1.1.2 > udp > dpts:30000:31000 > 5 ACCEPT tcp -- 0.0.0.0/0 10.1.1.2 > tcp > dpt:8443 > 6 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 > state > RELATED,ESTABLISHED > > 7 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 > > > Chain OUTPUT (policy ACCEPT) > num target prot opt source destination > > > Chain RH-Firewall-1-INPUT (0 references) > num target prot opt source destination > 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 > 2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 > icmp > type 255 > > 3 ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0 > 4 ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0 > 5 ACCEPT udp -- 0.0.0.0/0 224.0.0.251 > udp > dpt:5353 > 6 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 > udp > dpt:631 > 7 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 > tcp > dpt:631 > 8 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 > state > > NEW tcp dpt:5666 > 9 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 > state > > NEW tcp dpt:389 > 10 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 > state > NEW tcp dpt:53 > 11 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 > state > NEW udp dpt:53 > 12 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 > state > NEW tcp dpt:8443 > 13 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 > state > NEW tcp dpt:8080 > 14 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 > state > NEW tcp dpt:82 > 15 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 > state > NEW udp dpt:1194 > 16 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 > state > NEW tcp dpt:22 > 17 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 > state > NEW tcp dpt:80 > 18 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 > state > NEW tcp dpt:21 > 19 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 > state > NEW tcp dpt:443 > 20 REJECT all -- 0.0.0.0/0 0.0.0.0/0 > reject-with icmp-host-prohibited > > > > I did another tests with the settings above and i got the same > result as > before. ITSP Time out. Now in headers after frame 6 i see that > is set > the server's public ip address. Are these headers correct now > or they > are wrong again and they should looks differently? If they are > wrong > then why system sends the wrong headers? > > I'm attaching a new trace from my test when i changed the ip > address in > NAT settings and checked server behind nat. > > In trace i have altered: > > - my real domain with 'mydomain.net'. > - sipx server name with 'sipx.mydomain.com' > - server public ip address with '87.1xx.xxx.43' > > > Many thanks again for your time and trying to helping me :) > > > On Mon, 2010-07-05 at 10:26 -0400, Tony Graziano wrote: > > I will encourage you to look this over: > > > > > > > > http://blog.myitdepartment.net/wp-content/uploads/2009/11/Call-Setup-Example-sipXecs-through-ITSP1.pdf > > > > > > It may help explain things a little to you. > > > > On Mon, Jul 5, 2010 at 9:53 AM, Tony Graziano > > <[email protected]> wrote: > > I dont know why you have port 5070 and 5090 stated. > I assume > > your ITSP shows you registered via port 5080, and > its likely > > they will send you calls on 5080. When you send > calls to them, > > it should be on 5060, but in frame 14 you are > sending "to > > them" on port 5080. > > > > > > Can you explain why you have changed the ports from > defaults? > > I am sure the ITSP does not like the call being send > on port > > 5080, but they should be sending you a better > > explanation/error message. Did you ask them if they > allow > > that? I also see the transaction last about 2 > seconds, and the > > ITSP is not responding probably because they > probably don't > > like that and ignore the transaction altogether. > > > > > > 1. When you register to the ITSP, you should try to > register > > on port 5080. THe ITSP "should" try to send you > calls on the > > port you registered from. > > 2. Do not try to create a siptrunk freehand, instead > use one > > (like voip.ms) and alter the information for your > ITSP > > gateway/registrar. > > 3. Do not alter the port you send the ITSP calls on. > Instaed, > > just send them the calls on port 5060. > > 4. Please ensure you have ports 5060 (udp/tcp), 5080 > (udp) and > > 30000-31000 (udp) properly stated in your firewall. > Right now, > > there is no way the audio would work. > > > > > > > > > > > > > > On Mon, Jul 5, 2010 at 9:40 AM, [email protected] > > <[email protected]> wrote: > > 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, > [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. > > > > > > > > > > > > > > > > > > > > -- > > ====================== > > 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. > > > > > > > > > > > > -- > > ====================== > > 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. > > > > > > > > > > -- > ====================== > 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/
