On 27 February 2018 at 22:56, zrm <zrm@xxxxxxxxxxxxxxx> wrote: > On 02/27/2018 04:15 PM, Arturo Borrero Gonzalez wrote: >> >> On 26 February 2018 at 17:21, zrm <zrm@xxxxxxxxxxxxxxx> wrote: >>> >>> Is there any way for a user process to query whether a hypothetical >>> packet >>> would be accepted or rejected given the current rules and state? >>> >>> I know the transport protocol, source and destination, in-interface etc. >>> I >>> want to ask the kernel if a packet with those parameters would be >>> forwarded >>> or dropped. >>> >>> The specific thing I'm trying to do is to create a conntrack entry but >>> only >>> if such a packet would have created it. I know how to create the >>> conntrack >>> entry, the question is how to evaluate the condition first. >>> >>> I'm trying to avoid having to evaluate the rules manually, which is very >>> complicated and likely to result in bugs. And I'm not even sure how to >>> get >>> certain information to do that, like whether a packet would currently >>> match >>> the conntrack RELATED state. >>> >>> Is there some API to query this information? I imagine that could be >>> useful >>> for debugging as well. >> >> >> No such feature exists currently. You could try creating the packet by >> hand (scapy?) and injecting it to the stack to see where it goes. >> > > I had considered that, the trouble is then it actually *sends* the packet, > which could confuse the other endpoint if it gets an empty UDP packet > instead of one with a specific payload, or the forged packet is missing some > expected options or TCP flags that the one the real source will send in five > milliseconds would have etc. > > I also sometimes have to do specific source address or port translation and > the forged packet could create the "wrong" conntrack entry which could also > affect the verdict. > > I suspect ultimately the only proper way to do this is going to be with > support from a kernel module, but I've never done one of those before. Wait, why you don't let the entry to be created by the conntrack engine itself? -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
