Sean Darcy <seandarcy2@xxxxxxxxx> wrote:
> I'm using flowtable for udp voip packets:
>
> table ip filter {
> flowtable f {
> hook ingress priority 0 devices = { external , internal };
> }
> .........
> chain FORWARD {
> ...........
> udp dport { iax, 10000-65000 } flow offload @f
> ..........
>
> I'm having some issues with this, which sent me to read the docs more closely.
>
> https://www.kernel.org/doc/Documentation/networking/nf_flowtable.txt
> gives a similar example:
>
> table inet x {
> flowtable f {
> hook ingress priority 0 devices = { eth0, eth1 };
> }
>
> chain y {
> type filter hook forward priority 0; policy accept;
> ip protocol tcp flow offload @f
> ............
>
> and then says:
>
> The 'flow offload' action from the forward chain 'y' adds an entry to the
> flowtable for the TCP syn-ack packet coming in the reply direction.
>
> key words: "in the reply direction" ! Why in only one direction ? I
> would have thought it would be both directions. (In fact, I would have
> thought all TCP packets, not just syn-ack packets, would go through
> the flowtable bypass, which doesn't seem like a good idea.)
This probably refers to the moment when the entry is added to the flow
table.
The flow expression skips packets that are still in 'new' state, so it
won't attempt to offoad a 'connection' that won't come into existence
in the first place.
In case of tcp, when the syn/ack comes back, conntrack transitions the
connection to 'established'.
