René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[BUG] fw_chain_egress missing ct state established,related accept causes inbound TCP to fail with default egress deny on routed networks","articleBody":"### problem\n\n\nProblem\n\nWhen a routed network is configured with default egress policy Deny, inbound TCP connections to guest VMs fail even when the correct ingress firewall rules are present. The Virtual Router's nftables fw_chain_egress chain is missing a ct state established,related accept rule, causing return packets (e.g. TCP SYN-ACK) from the VM to be dropped by the final drop rule in fw_chain_egress.\n\nThe FORWARD chain correctly jumps traffic sourced from the guest subnet (ip saddr \u003cguest-subnet\u003e jump fw_chain_egress). However, fw_chain_egress only contains explicit port/protocol allow rules followed by a default drop — there is no connection tracking rule to permit return traffic for inbound connections that were allowed by fw_chain_ingress.\n\nNote: This issue only occurs when the network's default egress policy is Deny. Networks with default egress policy Allow are not affected — inbound TCP works correctly in that configuration.\n\n\n\n### versions\n\nCloudStack Management Server: 4.22.0.0-shapeblue0 (package: cloudstack-management)\nVirtual Router: 4.22.0 (Debian GNU/Linux 12 bookworm, kernel 6.1.0-40-arm64 aarch64)\nHypervisor: KVM\nNetwork type: Routed isolated network, dynamic BGP routing mode\nDefault egress policy: Deny\nSteps to reproduce\n\n### The steps to reproduce the bug\n\nObserved fw_chain_egress on VR (clean state, post-reboot):\n\n```\nchain fw_chain_egress {\n    ip saddr 0.0.0.0/0 ip daddr 0.0.0.0/0 icmp type { echo-reply, destination-unreachable, source-quench, redirect, echo-request, router-advertisement, router-solicitation, time-exceeded, parameter-problem, timestamp-request, timestamp-reply, info-request, info-reply, address-mask-request, address-mask-reply } accept\n    ip saddr 0.0.0.0/0 ip daddr 0.0.0.0/0 tcp dport 22 accept\n    counter packets 115 bytes 6900 drop\n}\n```\nExpected fw_chain_egress:\n\n```\nchain fw_chain_egress {\n    ct state established,related accept   ← missing\n    ip saddr 0.0.0.0/0 ip daddr 0.0.0.0/0 icmp type { ... } accept\n    ip saddr 0.0.0.0/0 ip daddr 0.0.0.0/0 tcp dport 22 accept\n    counter drop\n}\n```\nThis is the IPv4 analog of the issue fixed for IPv6 in PR #10970.\n\nCreate a zone with dynamic routing enabled and an IP subnet pool configured\nCreate a network offering with routing mode = Dynamic and default egress policy = Deny\nDeploy an isolated routed network using that offering\nIn the network's IPv4 Routing Firewall, add:\nIngress rule: TCP port 22 from 0.0.0.0/0\nEgress rule: TCP port 22 to 0.0.0.0/0\nDeploy a VM in the network\nAttempt to SSH to the VM from an external host\nConnection hangs\nDiagnosis: tcpdump on the VR confirms the SYN arrives on eth2, is forwarded out eth0 to the VM, the VM responds with SYN-ACK on eth0, but the SYN-ACK is dropped by the counter drop rule in fw_chain_egress because no ct state established,related accept rule exists.\n\nWorkaround\n\nManually insert the missing rule on the VR (lost on VR restart):\n\n\nnft insert rule ip ip4_firewall fw_chain_egress ct state established,related accept\nWhat to do about it?\n\nAdd ct state established,related accept as the first rule in fw_chain_egress in the VR nftables generation code. This should always be present regardless of user-defined egress rules, as it is required to allow return traffic for inbound connections permitted by fw_chain_ingress. This mirrors the fix applied for IPv6 in PR #10970.\n\n### What to do about it?\n\n_No response_","author":{"url":"https://github.com/khumps","@type":"Person","name":"khumps"},"datePublished":"2026-04-04T20:13:36.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":3},"url":"https://github.com/12962/cloudstack/issues/12962"}