Hi, I agree on all points of this mail. Some comments below. On Mon, 2013-04-22 at 22:05 +0200, Jesper Dangaard Brouer wrote: > First of all, thanks Tomasz for proposing to write a high level API for > nftables. +1 > Note to cc'ed people not on the netfilter-devel list can follow the > thread here: > http://thread.gmane.org/gmane.comp.security.firewalls.netfilter.devel/46734 ... > Use-case 2 > ----------- > Think this was Fabio's use-case during the netfilter workshop. > > An interface to dry run a packet through configured netfilter policy. > > This would allow user space to figure out if a specific daemon or > use-case can function in the configured environment. > > The feature is primarily intended for debugging and troubleshooting > purposes but can be extended later on, enabling daemons or daemon > management tools to verify if the daemon is permitted to run in the > configured specific environment. > > I guess, we also would need some kernel changes for supporting this? I think this point is really interesting. Being able to know for a given packet (IP tuple + ifaces)if it will get dropped or accepted or NAted (and with which transformation) could be really interesting. A more advanced related feature could be to have a TRACE like result . By the way, I've encountered today a TRACE limitation related to this point when debugging a firewall. I was investigating a NAT issue relative to a REJECT rule and TRACE was not tracing the sent ICMP message. And as for result, the NAT transformation made on the error message was not visible. This kind of information would be really useful if the test system is implemented. BR, -- Eric Leblond <eric@xxxxxxxxx> Blog: https://home.regit.org/ -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
