Question re: Nat & Port Forwarding: Use Policy Objects, or Attach to Zones?

[Joshua Kramer]

Hello,

It looks like there are a couple of ways to do port forwarding in NAT situations: either put the rules in the Zone itself, or use a Policy Object and put the port forwarding rules in the Policy Object.  Which is the "right" way to do it for this situation?

I have an appliance I'm building a firewall out of.  There are several Ethernet interfaces.  For this particular issue, two are important: eth0 is the interface that is connected to the Internet, and eth1 is connected to a VPN server.  eth1's network addr is 192.168.9.1 and the VPN server is 192.168.9.2.  When a UDP connection arrives on port 1195 on eth0, I want it to be forwarded to 1194 on eth1 to 192.168.9.2.  The Zone I have for eth0 is 'external' and the Zone I have for eth1 is 'vpnbox'.  The 'external' Zone is set to masquerade.

If I put the rule in the 'external' Zone, nothing happens- the connection is not forwarded.  This is true even if I open firewall holes in that Zone.

If I put the rule in a policy object with 'external' Zone as ingress and 'vpnbox' Zone as egress, I can't reload firewalld after creating the policy.  It comes back with an error, "INVALID_ZONE: Policy 'worldToVpnBox': 'forward-port' cannot be used because egress zone 'vpnbox' has assigned interfaces".

I did see this link, but it doesn't seem right that the rule should apply to ANY zone.  Isn't that a security risk or a potential for a misconfiguration?  https://firewalld.org/2020/09/policy-objects-filtering-container-and-vm-traf...

I am new to firewalld Policy objects and would greatly appreciate if someone could refer me to resources that would answer this question.

Thanks!
-JK

[Andrei Borzenkov]

On Tue, May 30, 2023 at 5:33 AM Joshua Kramer  wrote:
> Hello,
>
> It looks like there are a couple of ways to do port forwarding in NAT situations: either put the rules in the Zone itself, or use a Policy Object and put the port forwarding rules in the Policy Object.  Which is the "right" way to do it for this situation?
>
> I have an appliance I'm building a firewall out of.  There are several Ethernet interfaces.  For this particular issue, two are important: eth0 is the interface that is connected to the Internet, and eth1 is connected to a VPN server.  eth1's network addr is 192.168.9.1 and the VPN server is 192.168.9.2.  When a UDP connection arrives on port 1195 on eth0, I want it to be forwarded to 1194 on eth1 to 192.168.9.2.  The Zone I have for eth0 is 'external' and the Zone I have for eth1 is 'vpnbox'.  The 'external' Zone is set to masquerade.
>
> If I put the rule in the 'external' Zone, nothing happens- the connection is not forwarded.  This is true even if I open firewall holes in that Zone.
>
> If I put the rule in a policy object with 'external' Zone as ingress and 'vpnbox' Zone as egress, I can't reload firewalld after creating the policy.  It comes back with an error, "INVALID_ZONE: Policy 'worldToVpnBox': 'forward-port' cannot be used because egress zone 'vpnbox' has assigned interfaces".

Forwarding to an external address is out of firewalld control - it is
determined by host routing tables. Firewalld cannot decide which
egress interfaces will be used.
> I did see this link, but it doesn't seem right that the rule should apply to ANY zone.  Isn't that a security risk or a potential for a misconfiguration?  https://firewalld.org/2020/09/policy-objects-filtering-container-and-vm-traf...
>
> I am new to firewalld Policy objects and would greatly appreciate if someone could refer me to resources that would answer this question.
>
> Thanks!
> -JK
> _______________________________________________
> firewalld-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Eric Garver]

On Tue, May 30, 2023 at 02:33:02AM -0000, Joshua Kramer wrote:
> Hello,
>
> It looks like there are a couple of ways to do port forwarding in NAT
> situations: either put the rules in the Zone itself, or use a Policy
> Object and put the port forwarding rules in the Policy Object.  Which
> is the "right" way to do it for this situation?

Either of these are right. Neither is wrong.

I prefer to put everything in policies and leave zones empty (only
assigned interfaces). But that's a personal preference. FWIW, under the
hood they're identical.
> I have an appliance I'm building a firewall out of.  There are several
> Ethernet interfaces.  For this particular issue, two are important:
> eth0 is the interface that is connected to the Internet, and eth1 is
> connected to a VPN server.  eth1's network addr is 192.168.9.1 and the
> VPN server is 192.168.9.2.  When a UDP connection arrives on port 1195
> on eth0, I want it to be forwarded to 1194 on eth1 to 192.168.9.2.
> The Zone I have for eth0 is 'external' and the Zone I have for eth1 is
> 'vpnbox'.  The 'external' Zone is set to masquerade.
>
> If I put the rule in the 'external' Zone, nothing happens- the
> connection is not forwarded.  This is true even if I open firewall
> holes in that Zone.

I agree with the other subthread. You need to look at your routing
rules. If you have a route "192.168.9.0/24 via dev eth0 src
192.168.9.1" then it won't work. You may have to add a specific route to
your destination, e.g. "192.168.9.X/32 via dev eth1".

This is a routing problem. Not a firewall problem.

It's odd to use the same subnet for your LAN and VPN. I highly
discourage that.
> If I put the rule in a policy object with 'external' Zone as ingress
> and 'vpnbox' Zone as egress, I can't reload firewalld after creating
> the policy.  It comes back with an error, "INVALID_ZONE: Policy
> 'worldToVpnBox': 'forward-port' cannot be used because egress zone
> 'vpnbox' has assigned interfaces".

This is a limitation of the underlying firewall (nftables). Forward
ports are a destination NAT. DNAT happens in the prerouting phase. At
that point it's _not yet known_ what the egress path is, so you can't
match the egress interface.
> I did see this link, but it doesn't seem right that the rule should
> apply to ANY zone.  Isn't that a security risk or a potential for a
> misconfiguration?
> https://firewalld.org/2020/09/policy-objects-filtering-container-and-vm-traf...

ANY is required because of the limitation I described above.

[..]