IPv6 firewall: accept packets from related and established connections#10970
Conversation
|
@blueorangutan package |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 4.20 #10970 +/- ##
==========================================
Coverage 16.14% 16.15%
- Complexity 13253 13269 +16
==========================================
Files 5656 5657 +1
Lines 497893 497772 -121
Branches 60374 60364 -10
==========================================
+ Hits 80405 80408 +3
+ Misses 408529 408413 -116
+ Partials 8959 8951 -8
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
oh, I remember this issue, I had a fix more than one year ago. good finding @winterhazel |
|
@weizhouapache , does that mean lgty? |
|
@blueorangutan package |
|
@JoaoJandre a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 14043 |
|
@blueorangutan package |
|
@winterhazel a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 14105 |
weizhouapache
left a comment
There was a problem hiding this comment.
code lgtm
Not tested it yet
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-13739)
|
|
@blueorangutan package |
|
@weizhouapache a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✖️ el9 ✔️ debian ✖️ suse15. SL-JID 14852 |
|
@blueorangutan test |
|
@weizhouapache a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian Build Failed (tid-14212) |
|
@blueorangutan package |
|
@weizhouapache a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 14868 |
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
Tested with Ipv6 network and VPC SSH did not work prior to this change, it worked with this change an example of nft rules |
apache#10970) * IPv6 firewall: accept related packets and packets from established connections * Remove rule from input chain
…ted connections The systemvm Virtual Router's nftables `ip6 ip6_firewall fw_input` chain is created with policy=drop and only ICMPv6 accept rules. The IPv4 INPUT chain has the equivalent `iifname "eth2" ct state established,related accept` rule (added by `fw_router_routing()`); the IPv6 path has no such rule. Effect: any v6 connection the VR itself initiates outbound (BGP to upstream PE peers, NTP, DNS lookups, etc.) has its return traffic silently dropped at the v6 INPUT hook before TCP processes it. For Isolated v6 ROUTED networks this is fatal — BGP IPv6 sessions cannot establish, tenant /64 prefixes are never advertised upstream, and VMs in the network are unreachable from the IPv6 internet. PR apache#10970 added the equivalent rule to the FORWARD chain only (covering tenant VM return traffic). This commit adds the matching rule to the INPUT chain (covering VR-originated return traffic) by introducing `fw_router_routing_v6()` as the IPv6 mirror of `fw_router_routing()`. Verified end-to-end on ACS 4.22.0.0 KVM: before the patch, v6 BGP sessions stay in `Connect` indefinitely; tcpdump confirms PE responds with SYN-ACK but VR's TCP stack never sees the SYN-ACK (MD5 counters zero — drop happens at netfilter). After the patch, v6 BGP sessions reach `Established` within seconds and remain stable across subsequent tenant firewall rule updates. Fixes: apache#13171 Signed-off-by: Jason Ball <jball@resetdata.com>
…ted connections The systemvm Virtual Router's nftables `ip6 ip6_firewall fw_input` chain is created with policy=drop and only ICMPv6 accept rules. The IPv4 INPUT chain has the equivalent `iifname "eth2" ct state established,related accept` rule (added by `fw_router_routing()`); the IPv6 path has no such rule. Effect: any v6 connection the VR itself initiates outbound (BGP to upstream PE peers, NTP, DNS lookups, etc.) has its return traffic silently dropped at the v6 INPUT hook before TCP processes it. For Isolated v6 ROUTED networks this is fatal — BGP IPv6 sessions cannot establish, tenant /64 prefixes are never advertised upstream, and VMs in the network are unreachable from the IPv6 internet. PR apache#10970 added the equivalent rule to the FORWARD chain only (covering tenant VM return traffic). This commit adds the matching rule to the INPUT chain (covering VR-originated return traffic) by introducing `fw_router_routing_v6()` as the IPv6 mirror of `fw_router_routing()`. Verified end-to-end on ACS 4.22.0.0 KVM: before the patch, v6 BGP sessions stay in `Connect` indefinitely; tcpdump confirms PE responds with SYN-ACK but VR's TCP stack never sees the SYN-ACK (MD5 counters zero — drop happens at netfilter). After the patch, v6 BGP sessions reach `Established` within seconds and remain stable across subsequent tenant firewall rule updates. Fixes: apache#13171 Signed-off-by: Jason Ball <jball@resetdata.com>
The IPv6 fw_input chain currently accepts only ICMPv6 control traffic and policy=drop everything else. Return traffic for VR-initiated v6 connections (e.g. BGP SYN-ACKs from upstream peers) is silently dropped. PR apache#10970 added the equivalent rule to the v6 FORWARD chain but removed it from INPUT in its second commit. This restores it at chain creation, so it applies uniformly to all v6 input-hook chains (routed Isolated, non-routed Isolated, etc.). Tested on ACS 4.22.0.0 staging: - Routed Isolated v6 (IsolatedV6RoutedFiltered offering): BGP v6 sessions reach Established, tenant /64 advertised upstream. - Non-routed Isolated v6 (DualStack with VirtualRouter + SourceNat): fw_input contains the established/related accept rule and accepts return traffic. Resulting fw_input on both shapes: chain fw_input { type filter hook input priority filter; policy drop; icmpv6 type { ... } accept ct state established,related accept } Fixes: apache#13171 Refs: apache#10970 Co-authored-by: Bryan Lima <[email protected]> Signed-off-by: Jason Ball <jball@resetdata.com>
Description
The VR's firewall service automatically accepts packets from related and established connections when using IPv4. However, it does not for IPv6. Due to this, even if the egress rules allow a VM to send requests to a machine from outside the isolated network, it will not receive the response unless operators have allowed all ingress for the (sometimes dynamically allocated) port.
This PR adds a rule to the VR's IPv6 forward chain accepting response traffic (ingress from related and established connections), even if the operator has not explicitly allowed all ingress for the ports, thus matching the IPv4 firewall's behavior.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
How Has This Been Tested?
I introduced an IPv6 range to my environment.
I created a network offering for IPv6.
I created an isolated network with the network offering.
I added a VM to the network.
Then, I performed the following tests:
I validated that the VR had nftables rules in the forward and input chains allowing the ingress of related packets and packets from established connections.
Inside the VM, I tried to download a file from a machine outside the isolated network using IPv6. I validated that the download did not begin, because the egress traffic was not allowed.
I allowed the egress for ports 80 and 443.
Inside the VM, I tried to download a file from a machine outside the isolated network using IPv6 again. This time, the file was download successfully. Before the changes, the file would not be downloaded, because the VR was rejecting the response traffic.
I tried to login into the VM using SSH and IPv6. I validated that it was not possible because the ingress traffic for port 22 was not allowed.
I allowed ingress for port 22, and tried to login into the VM using SSH and IPv6 one more time. This time, I was able to access the VM successfully.