Re: [Shorewall-users] UPnP server inside a XEN DomU not talking to local net

[Jens Rehaag]

Am 13.10.2009 um 03:06 schrieb Tom Eastep: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jens Rehaag wrote: Hi, long story told shortly: I am running a MythTV backend (with UPnP server) inside a XEN DomU. Everything works fine, except for the UPnP part. Before I migrated the server to the virtual machine, also that was working well (broadcasting to a PS3 on the local net, and also to other UPnP software clients). Now, the clients don't see the server any more. My XEN/Shorewall setup is based on this guide: running Shorewall in a routed Dom0 <http://www.shorewall.net/XenMyWay-Routed.html>. Main difference is that I did not (yet) make a separate zone for the WLAN. Current environment: eth0: External interface (net) (to the Internet router), 192.168.200.1 eth1: Internal interface (loc), 192.168.100.1 eth4: UPnP server ($TEST_IF), 192.168.200.1 The internal address of the UPnP server is 192.168.100.3. Client used for testing: 192.168.100.222 (loc) After a lot of trial/error, and also a lot of googling, I'm stuck... I'm pretty sure I just overlooked one tiny detail, but can't see it. Can anyone give me a hint, please? Sorry if this was handled earlier on the list, but my search didn't turn it up. You'll find a shorewall dump in the attachment. Sorry -- I don't understand your configuration at all. You say: eth4: UPnP server ($TEST_IF), 192.168.200.1 That isn't the server -- that is an interface on the firewall. True - it's the interface XEN created for the virtual machine that is running the MythTV / UPnP server, using Proxy ARP: #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 192.168.200.10 $DMZ_IF $EXT_IF yes 192.168.100.3 $TEST_IF $INT_IF yes - From the dump: Chain PREROUTING (policy ACCEPT 176 packets, 40630 bytes) pkts bytes target     prot opt in     out     source destination    0     0 UPnP       all  --  eth0   *       0.0.0.0/0 0.0.0.0/0    0     0 UPnP       all  --  eth3   *       0.0.0.0/0 0.0.0.0/0   26  6595 UPnP       all  --  eth1   *       0.0.0.0/0 0.0.0.0/0   44 14522 UPnP       all  --  eth4   *       0.0.0.0/0 0.0.0.0/0    0     0 UPnP       all  --  vnet0  *       0.0.0.0/0 0.0.0.0/0    0     0 UPnP       all  --  vif10.0 *       0.0.0.0/0 0.0.0.0/0 Looks like you kept adding 'upnp' to your interfaces until you ran out of interfaces??? Yes, only had it on eth1 originally, but added it to others as well as part of that trial/error process... now on eth4 only. This is also curious: Chain eth0_masq (1 references) pkts bytes target     prot opt in     out     source destination    1    76 SNAT       all  --  *      *       192.168.100.0/24 0.0.0.0/0           /* Masquerade Local Network */ to:192.168.200.1    0     0 SNAT       all  --  *      *       169.254.0.0/16 0.0.0.0/0           /* Masquerade Local Network */ to:192.168.200.1    0     0 SNAT       all  --  *      *       239.0.0.0/8 0.0.0.0/0           /* Masquerade Local Network */ to:192.168.200.1    0     0 SNAT       all  --  *      *       224.0.0.0/4 0.0.0.0/0           /* Masquerade Local Network */ to:192.168.200.1 What is all of this masquerading for? Clearly the multicast addresses in the 'source' column are ridiculous which makes me think that you have an interface name in the SOURCE column of /etc/shorewall/masq. Yes, actually, I based it on your above mentioned document, which has  "$EXT_IF $INT_IF 206.124.146.179". I replaced the IP address with 192.168.200.1. Those multicast addresses are also mostly leftovers from testing, I had added them manually to the routing table. It looks to me like you have taken a server that depends on broadcast and have moved it to the other side of a router from its clients; that's usually a losing strategy. Do you have any web references about how this whole thing is supposed to work? My experience with UPnP is in the classic case where linux-idg is running on a gateway which this doesn't appear to be. Not really: What I did was to move a service (MythTV with UPnP) that was running directly on the firewall earlier into a virtual machine, also on the firewall. That virtual machine is supposed to be part of the local zone, that's why I thought linux-idg would not be needed (as I understood it was used to allow UPnP traffic between the net zone and the loc zone).  All clients are in the loc zone. The reference I used when I set up the MythTV server directly on the firewall earlier can be found here: http://www.mythtv.org/wiki/UPnP The broadcast route mentioned under "Troubleshooting" was indeed needed when I ran the server on the firewall. Now, I have it on the virtual machine. All other broadcast addresses cleaned, server rebooted. I will take a closer look at linux-idg, and also at broadcasting in general. I have attached a new dump, should be cleaner. Cheers,   Jens - -Tom - -- Tom Eastep        \ When I die, I want to go like my Grandfather who Shoreline,         \ died peacefully in his sleep. Not screaming like Washington, USA     \ all of the passengers in his car http://shorewall.net \________________________________________________ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrT0ocACgkQO/MAbZfjDLLS2gCeKyWDMpI/1TVSIjDI09pUgtmM q8wAoKN3CNYM2VQulQX0DUyhBqAWgqoa =LG3j -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

status_new.txt.gz
Description: GNU Zip compressed data

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users