Hi!
I want to try to install the Linux-IGD Daemon
(http://linux-igd.sourceforge.net/) which is a kind of UPnP over NAT daemon
which should allow UPnP aware clients to work properly from behind a NAT
firewall.
First of all, I read this on the Shorewall news pages:
*2/22/2002 - Shorewall 1.2.7 Released
*In this version:
*UPnP probes (UDP destination port 1900) are now silently dropped in the
common chain
Is there any way to get this port open again? (I need it I think :-)
Second, I read the README shipping with the UpNP daemon, and it says I need
to set some things on my firewall. In short I need to do this: (see lower
part of this email for the full readme)
1. Allow basically all tcp and udp through the
FORWARD chain to your client machines
1a. I don''t understand this exactly and don''t
know what I have to do here?????
2. client machines must be able to contact the firewall using
tcp and udp through the firewall''s INPUT chain on it
internal interface
2a. /etc/shorewall/policy
loc fw ACCEPT
fw loc ACCEPT
Is this correct? (and what about UDP port 1900?)
Thanks in advance for your answers :-)
Niels
*** README ***
NOTE: This program only creates DNAT (portmap) entries in you firewall on
the
external interface (public ip). Any other firewall code must be set to
allow
basically all tcp and udp through the FORWARD chain to your client machines,
and the client machines must be able to contact the firewall using tcp and
udp
through the firewall''s INPUT chain on it internal interface.
We will be adding some checks to see if FORWARD has a default policy of DROP
or
REJECT, however placing rules once we determine this is a bit tricky.
There''s
at the moment no real way to check to see if a packet matchin this rule will
pass through any additional rules that may be located above it. Also, we
will
probably need to check for any rules below as well. Hopefully we can get
this
implemented soon.
In the meantime, please be aware of this fact, and if you are seeing
Advertisements sent in the /var/log/debug file (or whatever you have syslog
set to log DEBUG level messages to), but you are not seeing AddPortMaps,
the most likely this is the problem, or it could be the following problem.
UPnP works with the 239.0.0.0/255.0.0.0 multicast addresses. Windows
Messenger
may also send request to a Unicast address, and thus the reason for the
patch
to the UPnP source code for this to work. Nevertheless, to add a route in
your box for the multicast address, just use the following command,
replaceing
<int_if> with the interface name of your inside interface name (i.e.,
eth0).
route add -net 239.0.0.0 netmask 255.0.0.0 <int_if>
That''s it, you''ll want to make sure your iptables rules
aren''t blocking this
as
well. Iptables has great strengths, but one of its weaknesses is no
usespace
api at the moment to help with us intelligently adding rules. So most of
getting this to work requires you understanding how UPnP works, and being
able
to adjust your firewall rules to this. The above should get you started,
however. It''s rather simple.
SECURITY NOTE: Please see the SECURITY file included with this distribution
about the consequences of using this software.
More information to come soon.
-- Glover George <dime@gulfsales.com>
--On Wednesday, December 04, 2002 04:16:07 PM +0100 niels@wxn.nl wrote:> Hi! > > I want to try to install the Linux-IGD Daemon > (http://linux-igd.sourceforge.net/) which is a kind of UPnP over NAT > daemon which should allow UPnP aware clients to work properly from behind > a NAT firewall. > > First of all, I read this on the Shorewall news pages: > > *2/22/2002 - Shorewall 1.2.7 Released > *In this version: > *UPnP probes (UDP destination port 1900) are now silently dropped in the > common chain > > Is there any way to get this port open again? (I need it I think :-)The ''common'' chain is traversed before a DROP or REJECT policy is applied. It is there simply to avoid producing log messages that produce thousands of posts from uses asking if their system is under attack. In the ''common'' chain UDP 1900 is dropped along with all NETBIOS chatter, broadcasts, etc. In other words, what''s in the common chain isn''t a problem for you.> > > Second, I read the README shipping with the UpNP daemon, and it says I > need to set some things on my firewall. In short I need to do this: (see > lower part of this email for the full readme) > > 1. Allow basically all tcp and udp through the > FORWARD chain to your client machines > > 1a. I don''t understand this exactly and don''t > know what I have to do here?????Neither do I. If you have to allow all net->loc traffic then what is the daemon for?> > 2. client machines must be able to contact the firewall using > tcp and udp through the firewall''s INPUT chain on it > internal interface > > 2a. /etc/shorewall/policy > loc fw ACCEPT > fw loc ACCEPT > > Is this correct? (and what about UDP port 1900?)Sigh...> > > > Thanks in advance for your answers :-) > > Niels > > > > *** README *** > > NOTE: This program only creates DNAT (portmap) entries in you firewall on > the > external interface (public ip). Any other firewall code must be set to > allow > basically all tcp and udp through the FORWARD chain to your client > machines, and the client machines must be able to contact the firewall > using tcp and udp > through the firewall''s INPUT chain on it internal interface.Sounds like this thing won''t play well with Shorewall since it will have no clue where to insert DNAT rules into Shorewall''s chain structure.> > We will be adding some checks to see if FORWARD has a default policy of > DROP or > REJECT, however placing rules once we determine this is a bit tricky. > There''s > at the moment no real way to check to see if a packet matchin this rule > will pass through any additional rules that may be located above it. > Also, we will > probably need to check for any rules below as well. Hopefully we can get > this > implemented soon.Again, I don''t think this is going to work.> > In the meantime, please be aware of this fact, and if you are seeing > Advertisements sent in the /var/log/debug file (or whatever you have > syslog set to log DEBUG level messages to), but you are not seeing > AddPortMaps, the most likely this is the problem, or it could be the > following problem. > > UPnP works with the 239.0.0.0/255.0.0.0 multicast addresses. Windows > Messenger > may also send request to a Unicast address, and thus the reason for the > patch > to the UPnP source code for this to work. Nevertheless, to add a route > in your box for the multicast address, just use the following command, > replaceing > <int_if> with the interface name of your inside interface name (i.e., > eth0). > > route add -net 239.0.0.0 netmask 255.0.0.0 <int_if> > > That''s it, you''ll want to make sure your iptables rules aren''t blocking > this as > well. Iptables has great strengths, but one of its weaknesses is no > usespace > api at the moment to help with us intelligently adding rules. So most of > getting this to work requires you understanding how UPnP works, and being > able > to adjust your firewall rules to this. The above should get you started, > however. It''s rather simple. > > SECURITY NOTE: Please see the SECURITY file included with this > distribution about the consequences of using this software.You will want to read that file carefully -- it sounds like this thing isn''t particularly secure and I doubt very seriously if it will work with Shorewall. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://shorewall.sf.net ICQ: #60745924 \ teastep@shorewall.net
--On Wednesday, December 04, 2002 07:27:14 AM -0800 Tom Eastep <teastep@shorewall.net> wrote:>> >> Second, I read the README shipping with the UpNP daemon, and it says I >> need to set some things on my firewall. In short I need to do this: (see >> lower part of this email for the full readme) >> >> 1. Allow basically all tcp and udp through the >> FORWARD chain to your client machines >> >> 1a. I don''t understand this exactly and don''t >> know what I have to do here????? > > Neither do I. If you have to allow all net->loc traffic then what is the > daemon for? >After further thought, I think that they want you to: ACCEPT net loc tcp ACCEPT net loc udp The daemon then uses DNAT rules to control access to your local systems from the net. So the solution depends entirely on SNAT/MASQ for security (and of course only works on a gateway that uses SNAT/MASQ). If you try this, be sure that you have ''norfc1918'' specified on your external interface because otherwise, hosts in your broadcast domain will have complete access to your local systems. -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://shorewall.sf.net ICQ: #60745924 \ teastep@shorewall.net