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: 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.orgiEYEARECAAYFAkrT0ocACgkQO/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 [email protected]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