L2 connection reset in local network wifi

[migs35323]

MetalLB Version

0.14.4

Deployment method

Charts

Main CNI

flannel (k3s built in)

Kubernetes Version

1.27.11

Cluster Distribution

k3s

Describe the bug

i have a raspberry pi cluster with 2-3 nodes that is connected to my router via ethernet cable,
i am able to reach metallb from the internet using port forwards to the LB IP and i am able to reach it as well if i have my computer plugged into the router ethernet ports
however when using the router's wifi connection i am greeted with a connection reset
i tried some tcpdumps as explained by the documentation
and to my surprise i get the GET request and arp from within the node and the speaker pod...
however it seems traffic is not reached into my ingress controller (a manual deployed traefik)
but as i said, this only happens if i try to connect to the raspberries trough my routers wifi

i tried to enable promiscious mode and had no effect (doesn't make sense since the raspberries wifi is disabled and i am not using it)

this issue doesn't happen if i use the default k3s load balancer

To Reproduce

1. in this setup i created a new OS install
2. did create a new k3s cluster with no traefik and no service load balancer flags as usual,
3. deployed metal lb using the helm chart

---
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: default-ip-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.69.200-192.168.69.210
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: default-ip-pool
  namespace: metallb-system
spec:
  ipAddressPools: 
    - default-ip-pool

5. applied traefik helm chart for ingress controller, as daemonset

heres the svc:

 apiVersion: v1
kind: Service
metadata:
  annotations:
    metallb.universe.tf/ip-allocated-from-pool: default-ip-pool
  labels:
    app.kubernetes.io/instance: traefik-traefik
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: traefik
    helm.sh/chart: traefik-26.1.0
  name: traefik
  namespace: traefik
spec:
  allocateLoadBalancerNodePorts: true
  clusterIP: 10.43.126.200
  clusterIPs:
  - 10.43.126.200
  externalTrafficPolicy: Local
  healthCheckNodePort: 32025
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  loadBalancerIP: 192.168.69.200
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.168.69.200

7. applied whoami service for testing

Expected Behavior

expect curl to reply with the whoami service:
this is the reply i get from a direct lan connection:

$ curl 192.168.69.200
Hostname: whoami-76c79d59c8-96jpg
IP: 127.0.0.1
IP: ::1
IP: 10.42.0.4
IP: fe80....
RemoteAddr: 10.42.0.2:35584
GET / HTTP/1.1
Host: 192.168.69.200
User-Agent: curl/7.88.1
Accept: */*
Accept-Encoding: gzip
X-Forwarded-For: 192.168.69.12
X-Forwarded-Host: 192.168.69.200
X-Forwarded-Port: 80
X-Forwarded-Proto: http
X-Forwarded-Server: traefik-xntj8
X-Real-Ip: 192.168.69.12

Additional Context

some additional info:

all my network is 192.168.69.0/24 (wifi and lan is the same network using the same router from ISP)
my raspberries have a static dhcp lease (for example, 192.168.69.10, 192.168.69.11...)
my computers/mobile devices have dinamic ips in another range (192.168.69.40-150)
and i did setup metallb L2 on 192.168.69.240
the raspberries are raspberry pi 4, using the normal raspberry os

I've read and agree with the following

• I've checked all open and closed issues and my request is not there.
• I've checked all open and closed pull requests and my request is not there.

I've read and agree with the following

• I've checked all open and closed issues and my issue is not there.
• This bug is reproducible when deploying MetalLB from the main branch
• I have read the troubleshooting guide and I am still not able to make it work
• I checked the logs and MetalLB is not discarding the configuration as not valid
• I enabled the debug logs, collected the information required from the cluster using the collect script and will attach them to the issue
• I will provide the definition of my service and the related endpoint slices and attach them to this issue

[cyclinder]

Can you confirm that the traffic has reached the node but not the service's endpoint?

[migs35323]

Can you confirm that the traffic has reached the node but not the service's endpoint?

yes that's that i found strange, i assumed it was my router having some restrictions from wifi->lan or something, because if i conenct a lan cable directly to the router it works fine
i did use tcpdump as instructed in the troubleshooting and i could see the get requests comming into the node and i could see the speaker pod also getting this request, but it doesnt' reach a simple load balancer > whoami deployment