Fix VPN traffic routing issue with iptables NAT rules - #14825

Claude finished @dguido's task —— View job

Comprehensive PR Review

I've conducted a thorough review of this critical iptables NAT routing fix. Here's my detailed analysis:

Review Checklist:

• Read and understand the problem described in PR description
• Analyze the iptables template changes in rules.v4.j2
• Analyze the iptables template changes in rules.v6.j2
• Review the new test file for coverage and quality
• Evaluate security implications of the changes
• Check for potential performance impacts
• Look for edge cases or potential regressions
• Provide comprehensive feedback and recommendations

Review Summary: ✅ EXCELLENT - Strongly Recommend Merge

This PR addresses a critical VPN functionality bug with a well-researched solution, comprehensive testing, and excellent technical execution.

Key Strengths

🎯 Problem Analysis & Solution

• Root cause correctly identified: The --pol none policy matching was indeed blocking decrypted VPN traffic from being NAT'd
• Solution is architecturally sound: Separates NAT rules by VPN type and removes unnecessary policy matching
• Maintains security: Keeps appropriate policy matching for IPsec FORWARD rules where it belongs

🧪 Exceptional Test Coverage

The new test file (tests/unit/test_iptables_rules.py) is exemplary:

• 188 lines of comprehensive test coverage
• Tests all critical scenarios: WireGuard-only, IPsec-only, both VPNs, SNAT vs MASQUERADE
• Regression-focused: Explicitly tests that the problematic --pol none patterns are absent
• Clear test names that document expected behavior
• Good mutation testing approach: Tests verify what should NOT be present

🔒 Security Assessment: SAFE

• No security regressions: IPsec FORWARD rules correctly retain --pol ipsec --dir in matching
• Principle of least complexity: Removes unnecessary policy matching where not needed
• Maintains VPN isolation: Client-to-client blocking rules unchanged
• No privilege escalation risks: Changes are within established firewall patterns

⚡ Performance Assessment: NEUTRAL TO POSITIVE

• Removes unnecessary checks: Eliminating --pol none matching reduces iptables processing overhead
• Separates rule logic: More explicit rule generation may slightly improve rule evaluation
• No additional rule complexity: Rule count remains the same

Technical Implementation Review

Template Changes (roles/common/templates/rules.{v4,v6}.j2)

Before (Problematic):

# Single rule for all VPN traffic with policy matching
-A POSTROUTING -s 10.48.0.0/16,10.49.0.0/16 -m policy --pol none --dir out -j MASQUERADE

After (Fixed):

# Separate, cleaner rules per VPN type
{% if ipsec_enabled %}
-A POSTROUTING -s {{ strongswan_network }} -j MASQUERADE
{% endif %}
{% if wireguard_enabled %}
-A POSTROUTING -s {{ wireguard_network_ipv4 }} -j MASQUERADE  
{% endif %}

Why this is correct:

1. NAT sees decrypted packets: Post-decryption, packets from VPN subnets need simple source-based NAT
2. WireGuard has no IPsec policies: Policy matching is meaningless for WireGuard traffic
3. Cleaner template logic: Separate rules per VPN type improve maintainability

FORWARD Rules Logic ✅

• IPsec FORWARD: Correctly keeps --pol ipsec --dir in (identifies encrypted traffic)
• WireGuard FORWARD: Correctly removes policy matching (not applicable)
• Maintains proper traffic flow control

Edge Cases & Regression Analysis

Scenarios Tested ✅

• Single VPN deployments (WireGuard-only, IPsec-only)
• Dual VPN deployments (both enabled)
• Alternative ingress IP (SNAT vs MASQUERADE)
• Policy matching presence/absence verification

Potential Edge Cases (None Critical)

1. Site-to-site VPN: If Algo ever supports this, NAT rules may need policy matching again
2. Multiple subnets: Current logic handles single subnet per VPN type
3. IPv6 NAT: Uses same logic as IPv4 (appropriate)

Code Quality Assessment

Template Quality ⭐⭐⭐⭐⭐

• Clear separation of concerns: Each VPN type has dedicated rule generation
• Consistent with existing patterns: Follows established Jinja2 conventions
• Good comments: Explains the purpose of each rule section
• DRY principle maintained: Reuses common SNAT/MASQUERADE logic

Test Quality ⭐⭐⭐⭐⭐

• Comprehensive coverage: Tests all NAT and FORWARD rule combinations
• Negative testing: Verifies problematic patterns are absent
• Real-world scenarios: Tests actual variable combinations used in deployment
• Self-documenting: Test names clearly explain what they verify

Minor Suggestions

1. Consider adding IPv6 test coverage: Current tests focus on IPv4 (though changes are symmetric)
2. Documentation: Consider updating any network troubleshooting docs to reference this fix

Conclusion

This is security-critical infrastructure code executed flawlessly:

• ✅ Fixes a critical bug affecting all VPN users
• ✅ Maintains security boundaries
• ✅ Comprehensive test coverage prevents regression
• ✅ Clean, maintainable implementation
• ✅ No breaking changes
• ✅ Excellent technical documentation in PR

Recommendation: Immediate merge - this fixes broken VPN functionality with no downsides.