[ovs-discuss] Issue with connection tracking for packets modified in pipeline

[Joe Stringer]

On 1 June 2017 at 05:23, Aswin S <aswinsuryan at gmail.com> wrote:
> Hi,
> When SG is implemented using conntrack rules , TCP connection via FIP
> between vms in the same compute is failing

What is SG?

Is FIP "floating IP"?

> In my topology I have two vm on the same compute both having floating ip
> associated with it and the fip translation is done using openflow rules.
>
> When using vm internal network ip it is working fine and I can ssh to the
> other vm.
>
> The conntrack event logs are as follows (Src ip 10.100.5.5 Dest Ip
> 10.100.5.12
>    [NEW] tcp      6 120 SYN_SENT src=10.100.5.5 dst=10.100.5.12 sport=43724
> dport=22 [UNREPLIED] src=10.100.5.12 dst=10.100.5.5 sport=22 dport=43724
> zone=5001
>  [UPDATE] tcp      6 60 SYN_RECV src=10.100.5.5 dst=10.100.5.12 sport=43724
> dport=22 src=10.100.5.12 dst=10.100.5.5 sport=22 dport=43724 zone=5001
>  [UPDATE] tcp      6 432000 ESTABLISHED src=10.100.5.5 dst=10.100.5.12
> sport=43724 dport=22 src=10.100.5.12 dst=10.100.5.5 sport=22 dport=43724
> [ASSURED] zone=5001
>
>
> But when I use FIP(the TCP packets are marked as Invalid and dropped.
> The SYN reaches the second vm which sends back the SYN ack and the status of
> conntrack entry is updated at the destination. Though the SYN-ACK reaches
> vm1 the conntrack state still remain UNREPLIED and the ack packet send to
> vm2 is marked as invalid and dropped. In the pipeline the packet is
> submitted to the conntrack both at egress and ingress side. The packet is
> submitted to conntrack after the fip modification.
>
> The conntrack event logs (Vm1 10.100.5.5, 192.168.56.29, Vm2 10.100.5.12,
> 192.168.56.23)
>
>      [NEW] tcp      6 120 SYN_SENT src=10.100.5.12 dst=192.168.56.29
> sport=58218 dport=22 [UNREPLIED] src=192.168.56.29 dst=10.100.5.12 sport=22
> dport=58218 zone=5001
>     [NEW] tcp      6 120 SYN_SENT src=192.168.56.23 dst=10.100.5.5
> sport=58218 dport=22 [UNREPLIED] src=10.100.5.5 dst=192.168.56.23 sport=22
> dport=58218 zone=5001
>  [UPDATE] tcp      6 60 SYN_RECV src=192.168.56.23 dst=10.100.5.5
> sport=58218 dport=22 src=10.100.5.5 dst=192.168.56.23 sport=22 dport=58218
> zone=5001

It looks like you're modifying the destination address on traffic from
VM1->VM2 before submitting to conntrack and modifying the source
address on traffic from VM2->VM1 before submitting to conntrack, which
means that conntrack is not seeing bidirection traffic between two
physical IPs, nor is it seeing bidirectional traffic between floating
IPs.. rather, it is seeing two unidirectional connections between
either VM1's physical IP and VM2's FIP, or VM1's FIP and VM2's
physical IP. The Linux connection tracker, when it sees unidirectional
SYNACK, will classify it as invalid, leading to your drop.

> The issue is not limited to TCP, if try with ICMP with FIP, the ping packet
> from vm1 to vm2 will be always new state in the connection tracker. This
> works(both TCP and ICMP) fine if the vm are two compute nodes. So is this an
> issue when a modified packet in the pipeline is  submitted to connection
> tracker? Does netfilter/ovs conntrack check for any other field than src ip/
> port dest ip/port for marking a packet as reply pakcet?

It deals with the actual packet contents when you execute the ct() action.

> I am using ovs 2.7.0. I have reported an issue a while ago[1] which still
> exsits and this seems to be related
>
> [1]https://mail.openvswitch.org/pipermail/ovs-discuss/2016-December/043228.html

It looks like you're seeing events corresponding to modified packets
according to your output above, so I don't see the relation to this
other thread.

Cheers,
Joe