When a remote client accesses a Windows container whose interface is attached to a Windows OVS, the reply packets of Windows container is not patched by Windows OVS correctly. For example:
Client IP: 192.168.240.220
Windows container IP: 10.10.3.10
Windows host IP: 192.168.240.203
For the client, it doesn't access the Windows container IP directly. The processing is like the following:
request packets
192.168.240.220:40000 -> 192.168.240.203:30008
192.168.240.220:40000 -> 169.254.0.252:30008 (DNAT by Windows NetNat)
192.168.240.220:40000 -> 10.10.3.10:80 (DNAT by OVS)
reply packets
10.10.3.10:80 -> 192.168.240.220:40000
169.254.0.252:30008 -> 192.168.240.220:40000 (unDNAT by OVS)
192.168.240.203:30008 -> 192.168.240.220:40000 (unDNAT by Windows NetNat)
For the 6th captured packet, before entering OVS, we can see the TCP checksum value is bf30, and it is the pseudo header checksum, not the checksum of TCP pseudo header, TCP header and TCP palyload. Note that, it is legal for Windows container to send packets with such TCP checksum.
After the packet is unDNATed by OVS, we can see that the source IP and source TCP port has been changed by OVS DNAT, as a result, the TCP checksum should be also updated. Note that, since there is no offload in OVS as well as in client, the checksum should be calculated from the data of TCP pseudo header, TCP header and TCP palyload after unDNAT. For the same 6th captured packet, we can see the TCP checksum is incorrect. The packet with the incorrect TCP checksum will be dropped by client, and we can see there are TCP Retransmission packets.
The TCP connection has the chance to work since after one or more times TCP Retransmission, there is a chance for Windows container to send a packet with correct TCP checksum value (calculated from TCP pseudo header, TCP header and TCP palyload), then OVS can also get the correct TCP checksum value after unDNAT, and the connection succeeds. However, there is also a chance for Windows container to always send packets with incorrect TCP checksum value (TCP pseudo header checksum), then the connection fails.
Here is the captured packets file showed in above pictures.
caps.tar.gz
When a remote client accesses a Windows container whose interface is attached to a Windows OVS, the reply packets of Windows container is not patched by Windows OVS correctly. For example:
For the client, it doesn't access the Windows container IP directly. The processing is like the following:
For the 6th captured packet, before entering OVS, we can see the TCP checksum value is
bf30, and it is the pseudo header checksum, not the checksum of TCP pseudo header, TCP header and TCP palyload. Note that, it is legal for Windows container to send packets with such TCP checksum.After the packet is unDNATed by OVS, we can see that the source IP and source TCP port has been changed by OVS DNAT, as a result, the TCP checksum should be also updated. Note that, since there is no offload in OVS as well as in client, the checksum should be calculated from the data of TCP pseudo header, TCP header and TCP palyload after unDNAT. For the same 6th captured packet, we can see the TCP checksum is incorrect. The packet with the incorrect TCP checksum will be dropped by client, and we can see there are
TCP Retransmissionpackets.The TCP connection has the chance to work since after one or more times
TCP Retransmission, there is a chance for Windows container to send a packet with correct TCP checksum value (calculated from TCP pseudo header, TCP header and TCP palyload), then OVS can also get the correct TCP checksum value after unDNAT, and the connection succeeds. However, there is also a chance for Windows container to always send packets with incorrect TCP checksum value (TCP pseudo header checksum), then the connection fails.Here is the captured packets file showed in above pictures. caps.tar.gz