Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Antrea TrafficControls do not handle Service traffic correctly #6957

Open
hongliangl opened this issue Jan 27, 2025 · 0 comments
Open

Antrea TrafficControls do not handle Service traffic correctly #6957

hongliangl opened this issue Jan 27, 2025 · 0 comments
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@hongliangl
Copy link
Contributor

Describe the bug
TrafficControls with redirect action don't handle Service connections correctly.

To Reproduce
Create a pair of veth interfaces and enable them on a K8s Node:

sudo ip link add veth0 type veth peer name veth1
sudo ip link set veth0 up
sudo ip link set veth1 up

Create a test client Pod, a test server Pod and a Service selecting the server Pod as backend.

Create a TrafficControl and apply it.

apiVersion: crd.antrea.io/v1alpha2
kind: TrafficControl
metadata:
  name: redirect-prod-to-local
spec:
  appliedTo:
    podSelector:
      matchLabels:
        app: busybox
  direction: Both
  action: Redirect
  targetPort:
    device:
      name: veth0
  returnPort:
    device:
      name: veth1

Run the command tcpdum -i veth1 -nve on the test Node.

Run the command curl <Service IP>:<Service Port> within the test client Pod. The request should succeed because we use a pair of veth interfaces, with nothing being between the interfaces. The output of tcpdum is:

  • 10.10.0.2 is the IP of the test client Pod.
  • 10.10.0.3 is the IP of the test server Pod.
  • 10.108.178.224 is the IP of the Service.

Similar to #6854, the issue is that the captured packets do not belong to the same connection, potentially being dropped by the engine like Suricata. This is because the reply packets should not be 'DNATed' before redirecting to veth0.

09:15:06.213615 6e:f7:b3:1a:f9:f5 > 96:67:a6:5f:9a:14, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 63, id 59915, offset 0, flags [DF], proto TCP (6), length 60)
    10.10.0.2.47434 > 10.10.0.3.80: Flags [S], cksum 0x2090 (correct), seq 2736516200, win 64860, options [mss 1410,sackOK,TS val 3443720138 ecr 0,nop,wscale 7], length 0
09:15:06.213726 6e:f7:b3:1a:f9:f5 > 72:67:5b:ec:c6:07, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    10.108.178.224.80 > 10.10.0.2.47434: Flags [S.], cksum 0xf192 (correct), seq 3512030931, ack 2736516201, win 64308, options [mss 1410,sackOK,TS val 2904926341 ecr 3443720138,nop,wscale 7], length 0
09:15:06.213790 6e:f7:b3:1a:f9:f5 > 96:67:a6:5f:9a:14, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 63, id 59916, offset 0, flags [DF], proto TCP (6), length 52)
    10.10.0.2.47434 > 10.10.0.3.80: Flags [.], cksum 0xcca6 (correct), ack 3512030932, win 507, options [nop,nop,TS val 3443720138 ecr 2904926341], length 0
09:15:06.213908 6e:f7:b3:1a:f9:f5 > 96:67:a6:5f:9a:14, ethertype IPv4 (0x0800), length 144: (tos 0x0, ttl 63, id 59917, offset 0, flags [DF], proto TCP (6), length 130)
    10.10.0.2.47434 > 10.10.0.3.80: Flags [P.], cksum 0x5ede (correct), seq 0:78, ack 1, win 507, options [nop,nop,TS val 3443720138 ecr 2904926341], length 78: HTTP, length: 78
        GET / HTTP/1.1
        Host: 10.108.178.224
        User-Agent: curl/7.76.1
        Accept: */*

09:15:06.213928 6e:f7:b3:1a:f9:f5 > 72:67:5b:ec:c6:07, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 63, id 65401, offset 0, flags [DF], proto TCP (6), length 52)
    10.108.178.224.80 > 10.10.0.2.47434: Flags [.], cksum 0x191e (correct), ack 79, win 502, options [nop,nop,TS val 2904926341 ecr 3443720138], length 0
09:15:06.214358 6e:f7:b3:1a:f9:f5 > 72:67:5b:ec:c6:07, ethertype IPv4 (0x0800), length 248: (tos 0x0, ttl 63, id 65402, offset 0, flags [DF], proto TCP (6), length 234)
    10.108.178.224.80 > 10.10.0.2.47434: Flags [P.], cksum 0xbc11 (correct), seq 1:183, ack 79, win 502, options [nop,nop,TS val 2904926342 ecr 3443720138], length 182: HTTP, length: 182
        HTTP/1.1 200 OK
        Date: Mon, 27 Jan 2025 09:15:06 GMT
        Content-Length: 65
        Content-Type: text/plain; charset=utf-8

        NOW: 2025-01-27 09:15:06.214225235 +0000 UTC m=+2071641.549915958 [|http]
09:15:06.214378 6e:f7:b3:1a:f9:f5 > 96:67:a6:5f:9a:14, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 63, id 59918, offset 0, flags [DF], proto TCP (6), length 52)
    10.10.0.2.47434 > 10.10.0.3.80: Flags [.], cksum 0xcba1 (correct), ack 183, win 506, options [nop,nop,TS val 3443720139 ecr 2904926342], length 0
09:15:06.214624 6e:f7:b3:1a:f9:f5 > 96:67:a6:5f:9a:14, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 63, id 59919, offset 0, flags [DF], proto TCP (6), length 52)
    10.10.0.2.47434 > 10.10.0.3.80: Flags [F.], cksum 0xcba0 (correct), seq 78, ack 183, win 506, options [nop,nop,TS val 3443720139 ecr 2904926342], length 0
09:15:06.214726 6e:f7:b3:1a:f9:f5 > 72:67:5b:ec:c6:07, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 63, id 65403, offset 0, flags [DF], proto TCP (6), length 52)
    10.108.178.224.80 > 10.10.0.2.47434: Flags [F.], cksum 0x1864 (correct), seq 183, ack 80, win 502, options [nop,nop,TS val 2904926342 ecr 3443720139], length 0
09:15:06.214754 6e:f7:b3:1a:f9:f5 > 96:67:a6:5f:9a:14, ethertype IPv4 (0x0800), length 66: (tos 0x0, ttl 63, id 59920, offset 0, flags [DF], proto TCP (6), length 52)
    10.10.0.2.47434 > 10.10.0.3.80: Flags [.], cksum 0xcb9f (correct), ack 184, win 506, options [nop,nop,TS val 3443720139 ecr 2904926342], length 0
@hongliangl hongliangl added the kind/bug Categorizes issue or PR as related to a bug. label Jan 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

No branches or pull requests

1 participant