Dude you should really step back and understand how rules are evaluated before you attempt to edit them..

So on your DMZ... How is your wan address ever going to be a source???

So you want your dmz net to only go to that 185.x.x.x address? Or is that your wan IP? And you think if you allow that it can talk to the internet??

The internet is not wan net, its not your wan IP... The internet is ANY!!! Your last rule there allows to internet.. All of those rules above that allow to that 185.x.x.x are pointless since your last rules allows everything. So uness you were going to log those rules.. What are they suppose to accomplish.

Why don't you state WHAT your wanting to do and we can walk through how to do that.

Also as already mentioned you can not just grab public IPs and use them on your network without issues. If you did own those IPs - why would you be natting to them?? So just at a complete loss to what your wanting to do exactly here. From your wan rules that looks like your port forwarding to that IP.. But then your dmz rules are allowing access to it? On udp for protocols that do not support UDP..

So again - why don't you draw up your network, what networks your using on your different vlans (rfc1918 I would assume) you don't have any public space routed to you - do you? And then what you would like to accomplish with firewall between your segments and any port forwards and we can walk through how to do that.

@newyork10023 said in pfBlockerNG rule element modification and ordering:

To begin, pfBlockerNG_devel 2.2.1_2 is awesome. Wow. Thanks.

Thanks!

Certain feeds are naughty. For example, adding RFC 1918 (Private Address Space), Multicast addresses, etc., etc., etc., is just BAD. Blocking possibly necessary system addresses, including multicast addresses, etc., is just NASTY. Adding a WhiteList is not going to fix this issue. These rule elements need to be culled from the list(s), and I mean permanently.

By chance are you using Firehol Level1? That feed contains bogons and should not be used for Outbound blocking. You can also enable "Suppression" which will remove local/loopback addresss.

A couple of feature suggestions for automatic rule insertion: use rule Separators to bind automatic rule insertion to specific places in the rules. (Indeed, one of my pet peeves is that automatic rules re-arrange Separator organization in seemingly random ways.). Another suggestion would be that automatic rule insertion should not re-arrange rule ordering AT ALL (after their initial placement). Subsequent rule updates should update rules IN PLACE. I like the possibility that Separators could be used to bind automatic rule insertion. But, disabling all automatic rule insertion needs to be an option for DNSBL.

Firewall rule separators will be very difficult to implement with pfBlockerNG and auto rules...