Alex/kaido-core
SHA256
Watch
1
0
Fork
You've already forked kaido-core
 0
Code Issues 10 Pull requests 1 Releases Activity Actions

Reply through the uplink a connection arrived on (reply-to) #120

New issue
Closed
opened 2026-11-10 17:58:38 +01:00 by Alex · 2 comments
Alex commented 2026-11-10 17:58:38 +01:00
Owner

Problem

  • Replies to connections that arrive on a non-default uplink follow normal routing and can leave through another uplink.
  • Example: two OpenStack ports in the same public subnet (eth0 mgmt, eth1 wan). The dashboard on the eth1 address is unreachable: the SYN-ACK leaves through eth0 and provider anti-spoofing drops it.
  • The same applies to port forwards on a second WAN and to ECMP multi-WAN, where replies are hashed independently of the ingress WAN.
  • pfSense and OPNsense solve this with automatic reply-to on interfaces that have a gateway.

Goal

  • Connections that arrive on an uplink with a gateway in the main routing context are answered through that uplink and gateway, both for local services and for forwarded traffic.

Plan: artifacts/tasks/120-reply-to/PLAN.md (local).

## Problem - Replies to connections that arrive on a non-default uplink follow normal routing and can leave through another uplink. - Example: two OpenStack ports in the same public subnet (eth0 mgmt, eth1 wan). The dashboard on the eth1 address is unreachable: the SYN-ACK leaves through eth0 and provider anti-spoofing drops it. - The same applies to port forwards on a second WAN and to ECMP multi-WAN, where replies are hashed independently of the ingress WAN. - pfSense and OPNsense solve this with automatic `reply-to` on interfaces that have a gateway. ## Goal - Connections that arrive on an uplink with a gateway in the main routing context are answered through that uplink and gateway, both for local services and for forwarded traffic. Plan: `artifacts/tasks/120-reply-to/PLAN.md` (local).
Alex commented 2026-11-10 19:15:26 +01:00
Author
Owner

Fixed by #123 (reply-to, ADR 0026). Kernel tests passed on the build VM (20/20).

Fixed by #123 (reply-to, ADR 0026). Kernel tests passed on the build VM (20/20).
Alex commented 2026-11-10 19:46:31 +01:00
Author
Owner

Reopened: with two uplinks in one subnet, senders inside that subnet still get no answer from the second uplink address, and router-originated traffic from it leaves through the first uplink. Cause: reply-to skips on-link senders, and the gateway and source tables lack the connected route; source rules match the shared subnet instead of the address. Fix: connected routes in gateway policy tables (reply-to covers on-link senders) and per-address source rules with connected routes.

Reopened: with two uplinks in one subnet, senders inside that subnet still get no answer from the second uplink address, and router-originated traffic from it leaves through the first uplink. Cause: reply-to skips on-link senders, and the gateway and source tables lack the connected route; source rules match the shared subnet instead of the address. Fix: connected routes in gateway policy tables (reply-to covers on-link senders) and per-address source rules with connected routes.
Alex closed this issue 2026-11-11 17:49:51 +01:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
119-example-firstboot
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Alex/kaido-core#120
No description provided.