On Thu, Feb 2, 2017 at 5:10 PM, Jarno Rajahalme <ja...@ovn.org> wrote:
> When looking for an existing conntrack entry, the packet 5-tuple
> must be inverted if NAT has already been applied, as the current
> packet headers do not match any conntrack tuple. For
> example, if a packet from private address X to a public address B is
> source-NATted to A, the conntrack entry will have the following tuples
> (ignoring the protocol and port numbers) after the conntrack entry is
> committed:
>
> Original direction tuple: (X,B)
> Reply direction tuple: (B,A)
>
> Now, if a reply packet is already transformed back to the private
> address space (e.g., with a CT(nat) action), the tuple corresponding
> to the current packet headers is:
>
> Current packet tuple: (B,X)
>
> This does not match either of the conntrack tuples above. Normally
> this does not matter, as the conntrack lookup was already done using
> the tuple (B,A), but if the current packet does not match any flow in
> the OVS datapath, the packet is sent to userspace via an upcall,
> during which the packet's skb is freed, and the conntrack entry
> pointer in the skb is lost. When the packet is reintroduced to the
> datapath, any further conntrack action will need to perform a new
> conntrack lookup to find the entry again. Prior to this patch this
> second lookup failed for NATted packets. The datapath flow setup
> corresponding to the upcall can succeed, however, allowing all further
> packets in the reply direction to re-use the conntrack entry pointer
> in the skb, so typically the lookup failure only causes a packet drop.
>
> The solution is to invert the tuple derived from the current packet
> headers in case the conntrack state stored in the packet metadata
> indicates that the packet has been transformed by NAT:
>
> Inverted tuple: (X,B)
>
> With this the conntrack entry can be found, matching the original
> direction tuple.
>
> This same logic also works for the original direction packets:
>
> Current packet tuple (after NAT): (A,B)
> Inverted tuple: (B,A)
>
> While the current packet tuple (A,B) does not match either of the
> conntrack tuples, the inverted one (B,A) does match the reply
> direction tuple.
>
> Since the inverted tuple matches the reverse direction tuple the
> direction of the packet must be reversed as well.
>
> Fixes: 05752523e565 ("openvswitch: Interface with NAT.")
> Signed-off-by: Jarno Rajahalme <ja...@ovn.org>
I could not apply this patch series to net-next branch. But it does
applies to net, which branch are you targeting it for?
