Table of Contents
Universal Plug and Play is intended to automate the installation and configuration of a small network as much as possible. This means that UPnP capable devices can join and leave a network without any effort of a network administrator.
The upnpd.lrp package provides
Internet Gateway Device services to the network. It
is a port of the linux-igd
project and UPnP SDK
project to the LEAF environment. The firewall will advertise
itself as an Internet Gateway to all UPnP control
points (clients). The clients can query the firewall to learn more about
its status (bandwidth, traffic statistics), but one of the most useful
features is the ability for client applications to request NAT/firewall
traversal.
While many common applications running on the Internet are simple
client requests which are NAT and firewall friendly (e.g. http), some
applications require the host behind the NAT/firewall device to receive
inbound sessions. Common examples of this include direct
connect features for instant messaging/multimedia conferencing
(e.g. AIM, MSN, Y! Messenger). Other examples include peer-to-peer
applications like Bittorrent and Gnutella. In each of these cases, the
clients act as temporary servers, but these clients may be desktop
machines that are assigned dynamic addresses and use dynamic port
assignment. Hand configured DNAT and FORWARD
rules on the firewall don't work well in such an environment.
For more information on UPnP, search the Intel and Microsoft websites for descriptions of UPnP. Alcatel has provided a good overview of the internals of the UPnP protocol and how it works with their SOHO routers, the basic concepts are similar and can be used to understand this implementation.
The Universal Plug-n-Play IGD protocol assumes that the devices on the inside of your firewall are trusted, -and- that there is only one exterior interface that requires NAT traversal. This is the common case in small offices and homes. Most SOHO routers shipped today support UPnP because it is such a useful feature. However, a malicious or compromised control point (client on your internal network) can potentially open up a hole in your firewall from the Internet to any port on any machine on your internal network. Additionally, this particular implementation has not undergone rigorous security testing and may be vulnerable to buffer overflows, allowing a malicious control point to gain unauthorized access to the firewall. It is imperative that only trusted hosts be allowed to interact with the UPnP services running on the firewall.
This implementation of UPnP IGD services assumes that there is a single UPnP client network (internal network) and a single external (Internet) connection. While it will run on a multi-port firewall, only one internal interface should be allowed to interact with the UPnP daemon. If you wish to use this on a firewall with multiple interfaces with different security policies, it is your responsibility to insure that your firewall policy does not allow a UPnP client on one interface to open up a hole in your firewall to a host on another interface.