miniupnp.tuxfamily.org Forum Index miniupnp.tuxfamily.org
The forum about miniupnp and libnatpmp
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

ipfilter rules wrong?

 
Post new topic   Reply to topic    miniupnp.tuxfamily.org Forum Index -> miniupnpd Compilation/Installation
View previous topic :: View next topic  
Author Message
nriley



Joined: 09 Jul 2008
Posts: 1

PostPosted: Wed Jul 09, 2008 8:41 pm    Post subject: ipfilter rules wrong? Reply with quote

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.

Code:

$ ipfstat -io
pass out quick on lo0 all
pass out quick on sis0 proto udp from 192.168.240.1/32 port = bootps to any port = bootpc
pass out quick on sis2 proto udp from 192.168.240.1/32 port = bootps to any port = bootpc
pass out quick on sis1 proto udp from any port = bootpc to any port = bootps
pass out quick on sis0 all keep state
pass out quick on sis1 all keep state
pass out quick on sis2 all keep state
block out log quick all
pass in quick on lo0 all
block in log quick from any to any with short
block in log quick from any to any with ipopts
pass in quick on sis0 proto udp from any port = bootpc to 255.255.255.255/32 port = bootps
pass in quick on sis0 proto udp from any port = bootpc to 192.168.240.1/32 port = bootps
pass in quick on sis2 proto udp from any port = bootpc to 255.255.255.255/32 port = bootps
pass in quick on sis2 proto udp from any port = bootpc to 192.168.240.1/32 port = bootps
block in log quick on sis1 from 192.168.240.0/24 to any
block in log quick on sis1 proto udp from any port = bootps to 192.168.240.0/24 port = bootpc
pass in quick on sis1 proto udp from any port = bootps to any port = bootpc
block in log quick on sis0 from !192.168.240.0/24 to any
block in log quick on sis2 from !192.168.240.0/24 to any
skip 1 in proto tcp from any to any flags S/FSRA
block in log quick proto tcp from any to any
block in log quick on sis0 all head 100
block in log quick on sis1 all head 200
block in log quick on sis2 all head 300
block in log quick all
block in all head miniupnpd
# Group 100
pass in quick from 192.168.240.0/24 to 192.168.240.1/32 keep state group 100
pass in quick from 192.168.240.0/24 to any keep state group 100
# Group 200
pass in quick proto tcp from any to 192.168.240.3/32 port = afpovertcp keep state group 200
[... more static port mappings which work fine ...]
# Group 300
pass in quick from 192.168.240.0/24 to any keep state group 300
# Group miniupnpd
pass in quick on sis1 proto udp from any to 192.168.240.5/32 port = mdns keep state group miniupnpd
pass in quick on sis1 proto udp from any to 192.168.240.5/32 port = 4502 keep state group miniupnpd
pass in quick on sis1 proto udp from any to 192.168.240.3/32 port = 53460 keep state group miniupnpd
pass in quick on sis1 proto udp from any to 192.168.240.3/32 port = mdns keep state group miniupnpd
pass in quick on sis1 proto udp from any to 192.168.240.3/32 port = 4501 keep state group miniupnpd
pass in quick on sis1 proto tcp from any to 192.168.240.3/32 port = 5900 flags S/FSRPAU keep state group miniupnpd


The ipnat rules look identical to the static ones so I didn't include that output.

Any idea what's going on?
Back to top
View user's profile Send private message
miniupnp
Site Admin


Joined: 14 Apr 2007
Posts: 1589

PostPosted: Thu Jul 10, 2008 9:04 am    Post subject: Reply with quote

I don't know ipfilter well but I'm wondering where are the rdr rules ?
_________________
Main miniUPnP author.
https://miniupnp.tuxfamily.org/
Back to top
View user's profile Send private message Visit poster's website
horseflesh



Joined: 29 Aug 2008
Posts: 6

PostPosted: Fri Aug 29, 2008 2:08 am    Post subject: Reply with quote

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?--

Quote:

The daemon will add ipnat rules (rdr's) and ipf rules to make sure your traffic gets in and through the system but you must have a head rule similar to this in your ipf.conf so that miniupnpd can add rules to let traffic in:

block in all head miniupnpd

You will also need two ipf rules to allow the multicast traffic in and the replies back out again:

pass in proto udp from any to 239.255.255.250 port = 1900
pass out proto udp from any port = 1900 to any


Thanks for any leads.
Back to top
View user's profile Send private message
horseflesh



Joined: 29 Aug 2008
Posts: 6

PostPosted: Fri Aug 29, 2008 2:08 am    Post subject: Reply with quote

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

http://blogs.sun.com/avalon/category/IPFilter
Back to top
View user's profile Send private message
miniupnp
Site Admin


Joined: 14 Apr 2007
Posts: 1589

PostPosted: Thu Mar 06, 2014 4:58 pm    Post subject: Reply with quote

horseflesh wrote:
Here's the link to the miniupnpd + ipf documentation.

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

looks like the source is not there anymore.
hopefuly there is archive.org https://web.archive.org/web/20110506013706/http://blogs.sun.com/avalon/category/IPFilter
_________________
Main miniUPnP author.
https://miniupnp.tuxfamily.org/
Back to top
View user's profile Send private message Visit poster's website
alimartin
Guest





PostPosted: Wed Apr 18, 2018 9:02 am    Post subject: Reply with quote

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.
Back to top
DanielW



Joined: 07 May 2018
Posts: 1

PostPosted: Mon May 14, 2018 11:07 am    Post subject: Reply with quote

Quote:

The daemon will recommend appetite suppressants for sure and add ipnat rules (rdr's) and ipf rules to make sure your traffic gets in and through the system but you must have a head rule similar to this in your ipf.conf so that miniupnpd can add rules to let traffic in:

block in all head miniupnpd

You will also need two ipf rules to allow the multicast traffic in and the replies back out again:

pass in proto udp from any to 239.255.255.250 port = 1900
pass out proto udp from any port = 1900 to any


Hi Martin, would you recommend placing all filter rules in one set as mandatory or can you get by with not doing that? I really want to avoid this for what I'm doing at the moment, but I also wouldn't want to ruin the project in the long run.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    miniupnp.tuxfamily.org Forum Index -> miniupnpd Compilation/Installation All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP
© 2007 Thomas Bernard, author of MiniUPNP.