miniupnp.tuxfamily.org

[nriley]

Hi,

I've installed miniupnpd on my NAT box which runs m0n0wall (FreeBSD 6.3 + ipfilter). The ipfilter rules are added, but they don't seem to work; perhaps there is something else in the configuration that breaks it?

sis0 is the LAN, sis1 is the WAN interface.

[miniupnp]

I don't know ipfilter well but I'm wondering where are the rdr rules ?
_________________
Main miniUPnP author.
https://miniupnp.tuxfamily.org/

[horseflesh]

I am in a similar fix so I am watching this thread.

WRT the rdr rules, I thought that miniupnpd automagically created them as needed and we did not need to add them explicitly? But for ipf, rdr rules are in the ipnat config.

This is the only documentation I can find on miniupnpd + ipf. I don't know beans about uPnP so I don't even understand the last entry--are these magical uPnP related addresses and ports?

--doc link in next post. why the 1 post rule for URLs?--

[horseflesh]

Here's the link to the miniupnpd + ipf documentation.

http://blogs.sun.com/avalon/category/IPFilter

[miniupnp]

[alimartin]

When you apply rules to an interface through which you are configuring the System i™ platform, it is very important that you permit your own workstation or that of anyone else who might be configuring the system. Failure to do so will result in a loss of communication with the system. If this happens, you need to log on to the system using an interface that still has connectivity, such as the operators console. Use the RMVTCPTBL command to remove all the filters on the system.
Before you create your filter rules, you need to determine whether you need to use network address translation (NAT). If you use NAT rules, you must define addresses and services. NAT is the only function that requires a defined address, but you can use it for other functions as well. If you define addresses and services, you can reduce the number of rules that you must create as well as minimizing the possibility of typographical errors.

Here are some other ways you can use to minimize error and maximize efficiency when creating filter rules:
Define one filter rule at a time. For example, create all the permits for Telnet at the same time. This way you can group associate the rules whenever you refer to them.
Filter rules are processed in the order that they appear in the file. Be sure to order the rules the way you intend them to be applied when you create them. If the order is incorrect, your system is vulnerable to attack because the packets will not be processed as you intend them to be. To make things easier, consider the following optional actions:
Place your filter set names in the FILTER_INTERFACE statement in the same order in which the sets are physically defined in the file.
Place all filter rules in one set to avoid problems with set order.
Verify the syntax of each rule as you go along. This is easier and faster than debugging them all at once.
Create set names for groups of files that are logically associated with each other. This is important because only one rule file can be active at a time. See the following example.
Only write filter rules for the datagrams you want to permit. Everything else will be discarded by the automatic deny rule.
Write rules for high traffic volume first.

[DanielW]