### What happened?

I have a 4-node (1 control-plane and 3 workers) cluster setup. Each node have two NICs, one for Pod network (inside 192.168.16.0/20), the other one for storage (inside 10.87.87.0/24).

I have a headless service, an operator would dynamically update its endpoints with storage NIC IPs. I cannot access this headless service (like `nc -vz <SERVICE-IP> <PORT>`) on nodes properly. But I can access other services on nodes.

### What did you expect to happen?

I should be able to access this headless service with secondary IPs just like other services from any node.

### How can we reproduce it (as minimally and precisely as possible)?

1. Setup a cluster with at least 2 Rocky8/9 nodes, each node needs to have two NICs
2. Assign different subnet and IP for two NICs
3. Create a nginx deployment but run each Pod with host network
4. Create a headless service and set its endpoints to IPs of secondary NIC of each nodes
5. Try `nc -vz <SERVICE-IP> 80` from any node. It will or will not succeed, depending on whether the service resolves to current node or node

### Anything else we need to know?

I've tried several combinations to rule out possible causes:

1. The problem exists on at least Rocky 8 and 9, with Kubernetes 1.25.12 and 1.30.0, with Calico, Flannel and Cilium CNI
2. The problem doesn't exist on Ubuntu 24.04, with Kubernetes 1.25.12, with Calico CNI

So it seems to me that it's not a CNI issue, but rather related to kube-proxy (or its combination with OS).

I also dug a little bit with tcpdump. It seems to me the source node did transmitted packets, but the source IP is the primary NIC's, not the secondary one's. This can be the real cause, but don't know what caused this.

And I can confirm that:

1. Connections between nodes via secondary NIC is OK, I can access the port via secondary NIC's IP normally
2. Firewall is stopped and disabled, selinux is turned off

### Kubernetes version

<details>

```console
$ kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.16", GitCommit:"c5f43560a4f98f2af3743a59299fb79f07924373", GitTreeState:"clean", BuildDate:"2023-11-15T22:39:12Z", GoVersion:"go1.20.10", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"30", GitVersion:"v1.30.0", GitCommit:"7c48c2bd72b9bf5c44d21d7338cc7bea77d0ad2a", GitTreeState:"clean", BuildDate:"2024-04-17T17:27:03Z", GoVersion:"go1.22.2", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.25) and server (1.30) exceeds the supported minor version skew of +/-1
```

</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
NAME="Rocky Linux"
VERSION="9.3 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.3"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.3 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2032-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.3"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.3"
$ uname -a
Linux kube-1 5.14.0-362.8.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 8 17:36:32 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>

Selector-less service with secondary IPs not working properly on Rocky 8/9 with latest kube-proxy
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : Selector-less service with secondary IPs not working properly on Rocky 8/9 with latest kube-proxy
Issue date:

--- start body ---
### What happened?

I have a 4-node (1 control-plane and 3 workers) cluster setup. Each node have two NICs, one for Pod network (inside 192.168.16.0/20), the other one for storage (inside 10.87.87.0/24).

I have a headless service, an operator would dynamically update its endpoints with storage NIC IPs. I cannot access this headless service (like `nc -vz <SERVICE-IP> <PORT>`) on nodes properly. But I can access other services on nodes.

### What did you expect to happen?

I should be able to access this headless service with secondary IPs just like other services from any node.

### How can we reproduce it (as minimally and precisely as possible)?

1. Setup a cluster with at least 2 Rocky8/9 nodes, each node needs to have two NICs
2. Assign different subnet and IP for two NICs
3. Create a nginx deployment but run each Pod with host network
4. Create a headless service and set its endpoints to IPs of secondary NIC of each nodes
5. Try `nc -vz <SERVICE-IP> 80` from any node. It will or will not succeed, depending on whether the service resolves to current node or node

### Anything else we need to know?

I've tried several combinations to rule out possible causes:

1. The problem exists on at least Rocky 8 and 9, with Kubernetes 1.25.12 and 1.30.0, with Calico, Flannel and Cilium CNI
2. The problem doesn't exist on Ubuntu 24.04, with Kubernetes 1.25.12, with Calico CNI

So it seems to me that it's not a CNI issue, but rather related to kube-proxy (or its combination with OS).

I also dug a little bit with tcpdump. It seems to me the source node did transmitted packets, but the source IP is the primary NIC's, not the secondary one's. This can be the real cause, but don't know what caused this.

And I can confirm that:

1. Connections between nodes via secondary NIC is OK, I can access the port via secondary NIC's IP normally
2. Firewall is stopped and disabled, selinux is turned off

### Kubernetes version

<details>

```console
$ kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.16", GitCommit:"c5f43560a4f98f2af3743a59299fb79f07924373", GitTreeState:"clean", BuildDate:"2023-11-15T22:39:12Z", GoVersion:"go1.20.10", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"30", GitVersion:"v1.30.0", GitCommit:"7c48c2bd72b9bf5c44d21d7338cc7bea77d0ad2a", GitTreeState:"clean", BuildDate:"2024-04-17T17:27:03Z", GoVersion:"go1.22.2", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.25) and server (1.30) exceeds the supported minor version skew of +/-1
```

</details>


### Cloud provider

<details>

</details>


### OS version

<details>

```console
# On Linux:
$ cat /etc/os-release
NAME="Rocky Linux"
VERSION="9.3 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.3"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.3 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2032-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.3"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.3"
$ uname -a
Linux kube-1 5.14.0-362.8.1.el9_3.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 8 17:36:32 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here
```

</details>


### Install tools

<details>

</details>


### Container runtime (CRI) and version (if applicable)

<details>

</details>


### Related plugins (CNI, CSI, ...) and versions (if applicable)

<details>

</details>

--- end body ---

The issue describes a problem with accessing a headless service using secondary IPs on Rocky Linux 8/9 with Kubernetes. This is likely a configuration or compatibility issue rather than a security vulnerability. The problem seems to stem from kube-proxy's handling of network interfaces and IPs, which does not constitute a security risk but rather a functional bug.