[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Inbound sip not detected by asterisk in Xen domU


  • To: "Christopher Isip" <cmisip@xxxxxxxxx>
  • From: "Todd Deshane" <deshantm@xxxxxxxxx>
  • Date: Tue, 13 May 2008 09:23:27 -0400
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 13 May 2008 06:24:16 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LVfzTsCFSnpun/eUR3IQO8+9OlOhZn77LuHBNhNuspddWeIsApoBLk8kxdfaOpGoxDtlfz104zUJl/CYUQ13Z4KTcOT4qu97cpG4JnPFl5sawEMKYxNma1WG1wp8y56x1UHL6XdEvEd3wyTT8OZVV2wK3C13+dG9PdKHAk90Nhc=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

Hi Chris,

On Mon, May 12, 2008 at 10:59 PM, Christopher Isip <cmisip@xxxxxxxxx> wrote:
I realize that this might not be at all a xen issue but I want to be sure because the setup "should" work.  I have a xen Asterisk DomU to which I assigned a physical nic (pciback) and this connects to the ISP.  The xen DomU also has a vif that is connected to the bridge in dom0.  The xen  Asterisk domU is firewalled with shorewall and is doing IP masq for the rest of the domU's and lan computers:

/etc/shorewall/interfaces  
net eth0 detect routefilter,norfc1918,tcpflags
loc eth1 detect tcpflags

/etc/shorewall/zones
fw      firewall
loc     ipv4
net     ipv4

/etc/shorwall masq
eth0 eth1

/etc/shorewall/policy
fw all ACCEPT
loc fw ACCEPT
loc net ACCEPT
all all DROP

/etc/shorewall/rules
ACCEPT     net    fw    udp    4569,5060:5061,10000:20000
ACCEPT     net    fw    tcp    4569,5060:5061,10000:20000

#/sbin/ifconfig

eth0      Link encap:Ethernet  HWaddr 00:12:3F:B4:98:EA
          inet addr:12.XX.XX.XX  Bcast:255.255.255.255  Mask:255.255.252.0
          inet6 addr: fe80::212:3fff:feb4:98ea/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2053062 errors:0 dropped:0 overruns:0 frame:0
          TX packets:648311 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1037207261 (989.1 MiB)  TX bytes:43878683 (41.8 MiB)

eth1      Link encap:Ethernet  HWaddr 00:16:3E:70:21:02
          inet addr:192.168.0.4  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::216:3eff:fe70:2102/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:776173 errors:0 dropped:0 overruns:0 frame:0
          TX packets:713553 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:70910867 (67.6 MiB)  TX bytes:947947605 (904.0 MiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:165207 errors:0 dropped:0 overruns:0 frame:0
          TX packets:165207 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:17730765 (16.9 MiB)  TX bytes:17730765 (16.9 MiB)


Everything works fine as far as browsing the net, downloading etc.  I can even
use my SIP phone to call out.  However sip calls originating outside the firewall cannot get in. 
The ISP hasn't blocked the port cause an old non xen box I have ( its dying, thats why I am migrating to a new xenified box.)

The old box (non xen) had the same exact configuration (to the best of my knowledge although the new one is asterisk 1.4 while the old one is 1.2). 

Is there any peculiar way that xen handles incoming packets that might cause this?
This xen asterisk domU used to have only one nic with the dom0doing the natting but I had one way audio problems, although incoming and outgoing calls were both possible.  I hoped that by configuring the asterisk domU to be the firewall and nat server as well, I could avoid the nat  related issue of one way audio.  And then this problem crept in.

The DomU is Centos Plus.  


It seems like it is something that should work, but that either a configuration problem or a bug somewhere could cause it not to.

Can you take network traces on the different points, including the particular vifs in question to see what traffic is seen?

I would also recommend double-checking firewall rules and anything else that could cause a potential problem.

Cheers,
Todd


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.