Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-48327

sourceRanges does not work in ssipv6 LBs with OVN provider

XMLWordPrintable

    • +
    • Moderate
    • None
    • 2
    • ShiftStack Sprint 265
    • 1
    • False
    • Hide

      None

      Show
      None

      Description of problem:

      Testcase from openstack-test fails in ssipv6 environment:

      "[sig-installer][Suite:openshift/openstack][lb][Serial] The Openstack platform should limit service access on an UDP OVN LoadBalancer when an UDP LoadBalancer svc setting the loadBalancerSourceRanges spec is created on Openshift"

      Same is working in dualstack with both ipv4primary and ipv6primary.

      The loadbalancer generated creates an SG and it's successfully attached to the members of the loadbalancer, that is, the primary interfaces of the masters and the workers. However the traffic is not being correctly filtered.

      Version-Release number of selected component (if applicable):

      4.18.0-0.nightly-2025-01-08-044301
      RHOS-17.1-RHEL-9-20241030.n.1
      

      How reproducible:

      Always
      

      Steps to Reproduce: Run mentioned testcase on a ssipv6 where the cloud-provider-config has been updated to use OVN provider. The code of the test can be found on https://github.com/openshift/openstack-test/blob/main/test/extended/openstack/loadbalancers.go#L631

      The svc has basically below definition:

      spec:
        allocateLoadBalancerNodePorts: true
        clusterIP: fd02::1bae
        clusterIPs:
        - fd02::1bae
        externalTrafficPolicy: Cluster
        internalTrafficPolicy: Cluster
        ipFamilies:
        - IPv6
        ipFamilyPolicy: SingleStack
        loadBalancerSourceRanges:
        - 2001:db8:2222:5555::/64
        ports:
        - nodePort: 32120
          port: 8082
          protocol: UDP
          targetPort: 8081
        selector:
          app: udp-lb-sourceranges-dep
        sessionAffinity: None
        type: LoadBalancer
      

      As a consequence, an LB is created and a SG is attached to the primary interfaces of the nodes (the LB members):

      $ openstack port show ostest-t6s2h-worker-0-lq6p7-0 -c security_group_ids
      +--------------------+----------------------------------------------------------------------------+
      | Field              | Value                                                                      |
      +--------------------+----------------------------------------------------------------------------+
      | security_group_ids | 13157556-ec40-4bb2-9ceb-f63496ab2a85, ef088ae8-e77c-420e-acfb-872c42f7234b |
      +--------------------+----------------------------------------------------------------------------+
      
      $ openstack security group rule list ef088ae8-e77c-420e-acfb-872c42f7234b >> lb.txt
      +--------------------------------------+-------------+-----------+-------------------------+-------------+-----------+-----------------------+----------------------+
      | ID                                   | IP Protocol | Ethertype | IP Range                | Port Range  | Direction | Remote Security Group | Remote Address Group |
      +--------------------------------------+-------------+-----------+-------------------------+-------------+-----------+-----------------------+----------------------+
      | 5321b606-1cd2-4858-9058-b6a81ba1b1b0 | udp         | IPv6      | 2001:db8:2222:5555::/64 | 32120:32120 | ingress   | None                  | None                 |
      +--------------------------------------+-------------+-----------+-------------------------+-------------+-----------+-----------------------+----------------------+
      

      However, above rule is not applied and all the traffic is passing.

      Actual results:

      The traffic is passing when it shouldn't.
          

      Expected results:

      The traffic should be blocked when the source IP is not matching the condition.
          

      Additional info:

      must-gather and sos-report linked on private comment.
          

              emacchi@redhat.com Emilien Macchi
              rlobillo Ramón Lobillo
              Itshak Brown Itshak Brown
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: