Description of problem: Using different zones for the public interface of a Fedora server configured as a router, firewalld does not allow forwarding for IPv6 even though it is allowed for IPv4. Version-Release number of selected component (if applicable): 0.4.4.4-1.fc25 How reproducible: Every time Steps to Reproduce: 1. Associate the egress interface, e.g. eth0, with a zone, e.g. public or FedoraServer. 2. For IPv4, it will include the rule (iptables -S output): -A FWDO_<zone>_allow -m conntrack --ctstate NEW -j ACCEPT 3. The same rule is not included for IPv6 (ip6tables -S output). 4. As a result, even though net.ipv6.conf.*.forwarding is 1, only ICMPv6 traffic can flow through the router/firewall. Actual results: Outbound "connections" can be initiated over IPv4, but not over IPv6 Expected results: Forwarding behavior should be consistent on both stacks. Additional info:
There is of course: firewall-cmd --permanent --direct --add-rule ipv6 filter FORWARD 0 -o eth0 -m conntrack --ctstate NEW -j ACCEPT but that seems like a workaround.
The rule for IPv4 is only generated in a zone where masquerading has been enabled. From the firewalld.zone man page: masquerade Is an optional empty-element tag. It can be used only once in a zone configuration and is not usable for IPv6. ... From the firewall-cmd man page: [--permanent] [--zone=zone] --add-masquerade [--timeout=timeval] Enable IPv4 masquerade for zone. ... But I agree that it might be good to change masquerading and port-forwarding in a zone also for IPv6 with an RFE. For IPv6 masquerading you can use rich rules.
What I'm after is to designate an *interface* as an egress interface for the server/router (it's an OpenVPN server box FWIW). It also seems correct to do that without introducing a dependency from the firewall rules to specific address ranges/subnets that happen to be assigned to different interfaces. Masquerading gets this done for IPv4, but for IPv6 the preferred way is to not masquerade/NAT but just to allow FORWARD packets that are exiting from the egress interface to do so. The "internal" (VPN LAN) subnets have their own globally routable IPv6 subnets, and the upstream router already routes those to my box's external/egress interface. If I'm reading the rich language docs correctly, I can't really specify an *interface* there - I have to use address ranges. Is that correct?
Typo, meant "internal (VPN LAN) interfaces have their own globally routable IPv6 subnets" above
Rich rules do not support the use of interfaces, but zones do.
I see, although even in a zone and using rich rules, I don't see how I could specify a policy of "ACCEPT packets if they are to be FORWARDed outbound on eth0". So I think the RFE I'm asking for is for a "pure" routing property in a zone (applicable to whichever interface(s) it's attached to - might be via NM) - no NAT or port/protocol restrictions.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.