Hi,
I'm trying to use the new policy objects to only allow outgoing packets destined for the vpn server or the vpn tunnel. I have been able to get the first part to work (establish a connection), but I can't get the tunnel traffic to flow.
Previously, with the direct interface and the iptables backend, I would have used the direct rules
ipv4 filter OUTPUT 0 -o lo -j ACCEPT ipv4 filter INPUT 0 -i lo -j ACCEPT ipv4 filter OUTPUT 10 -p udp --dport 443 -d <vpn.ip.address> -j ACCEPT ipv4 filter OUTPUT 998 -o tun+ -j ACCEPT ipv4 filter FORWARD 2 -o tun+ -j ACCEPT ipv4 filter FORWARD 2 -i tun+ -j ACCEPT ipv4 filter INPUT 999 -j DROP ipv4 filter OUTPUT 999 -j DROP ipv4 filter FORWARD 999 -j DROP ipv6 filter OUTPUT 0 -j DROP ipv6 filter INPUT 0 -j DROP ipv6 filter FORWARD 0 -j DROP
Instead, I'm trying to use the policy:
myvpnpol (active) priority: -1 target: DROP ingress-zones: HOST egress-zones: ANY services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" destination address="<vpn.ip.address>" port port="443" protocol="udp" accept
Also, my default zone is set to "drop", and I'm using the nftables backend.
Note, since I'm on version 0.9 rather than 1.0, which means I don't have the patch in https://github.com/firewalld/firewalld/pull/709. I also add the following nft rule by hand (which gets wiped on a reload)
nft insert rule inet firewalld filter_OUTPUT index 0 ct state { established, related } accept
I don't mind using this hack for now because I want to try and use the new policy framework and the nftables backend, and I know I can stop using it with version 1.0.
With this set up, I can establish a new openvpn connection. However, all the traffic to the tun0 interface is dropped by the "myvpnpol" policy. I was wondering if there was a way to handle this in firewalld, without using the direct options (-o tun+ -j ACCEPT) with the iptables backend, or adding a few more nft entries by hand (oifname "tun0" accept). If this isn't possible in 0.9, or 1.0, does anyone know how this might be handled in the future? Could the tunnel interface be assigned to a zone, or would it be handled by rich rules?
On Sun, Jul 25, 2021 at 02:03:44PM -0000, Fedora Borealis wrote:
Hi,
I'm trying to use the new policy objects to only allow outgoing packets destined for the vpn server or the vpn tunnel. I have been able to get the first part to work (establish a connection), but I can't get the tunnel traffic to flow.
Previously, with the direct interface and the iptables backend, I would have used the direct rules
ipv4 filter OUTPUT 0 -o lo -j ACCEPT ipv4 filter INPUT 0 -i lo -j ACCEPT ipv4 filter OUTPUT 10 -p udp --dport 443 -d <vpn.ip.address> -j ACCEPT ipv4 filter OUTPUT 998 -o tun+ -j ACCEPT ipv4 filter FORWARD 2 -o tun+ -j ACCEPT ipv4 filter FORWARD 2 -i tun+ -j ACCEPT ipv4 filter INPUT 999 -j DROP ipv4 filter OUTPUT 999 -j DROP ipv4 filter FORWARD 999 -j DROP ipv6 filter OUTPUT 0 -j DROP ipv6 filter INPUT 0 -j DROP ipv6 filter FORWARD 0 -j DROP
Instead, I'm trying to use the policy:
myvpnpol (active) priority: -1 target: DROP
Since you used DROP here that means all outgoing traffic (e.g. DNS) is blocked _except_ the HTTPS (443) that you allow via rich rule. That's probably not what you want. That may explain why connecting to the VPN via address works (no DNS lookup), but other traffic does not.
Your direct rules above explicitly allow all packets that leave via tun+.
ingress-zones: HOST egress-zones: ANY
services: ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: rule family="ipv4" destination address="<vpn.ip.address>" port port="443" protocol="udp" accept
I think in addition to the above policy you need a second one to accept all traffic destined to tun+. Put tun+ in a zone, then add that zone the egress-zones set. Make sure this new policy has a higher precedence (lower priority value) than the one above.
Also, my default zone is set to "drop", and I'm using the nftables backend.
That's fine. As the zone target applies to traffic destined for the HOST.
Note, since I'm on version 0.9 rather than 1.0, which means I don't have the patch in https://github.com/firewalld/firewalld/pull/709. I also add the following nft rule by hand (which gets wiped on a reload)
My bad. I must have missed that fix when I recently pulled fixes to the stable branches. I did it just now. The above fix will be in v0.9.5.
nft insert rule inet firewalld filter_OUTPUT index 0 ct state { established, related } accept
I don't mind using this hack for now because I want to try and use the new policy framework and the nftables backend, and I know I can stop using it with version 1.0.
With this set up, I can establish a new openvpn connection. However, all the traffic to the tun0 interface is dropped by the "myvpnpol" policy. I was wondering if there was a way to handle this in firewalld, without using the direct options (-o tun+ -j ACCEPT) with the iptables backend, or adding a few more nft entries by hand (oifname "tun0" accept). If this isn't possible in 0.9, or 1.0, does anyone know how this might be handled in the future? Could the tunnel interface be assigned to a zone, or would it be handled by rich rules?
I think I answered all of this inline above.
I think in addition to the above policy you need a second one to accept all traffic destined to tun+. Put tun+ in a zone, then add that zone the egress-zones set. Make sure this new policy has a higher precedence (lower priority value) than the one above.
Thanks for the insights, I'll try that. Nice that you're bringing in the fix to v0.9.5 :)
I'm not familiar with setting the zone for a tun0 device. Currently the tun0 interface has no zone assigned to it (not even the default). I currently run openvpn directly as part of a script so that I can easily change the destination ip address (along with changing the firewall just before hand to allow only that address). I'm not that familiar with using network manager (either gui or client) for openvpn connections. Doing some brief digging I've found that I can set the zone using
nmcli connection modify tun0 connection.zone myzone
but this probably isn't the preferred approach since the tun0 device only lasts within the openvpn session.
Should I just delve into using network manager proper for the openvpn client connections, saving the configuration (and zone setting)? Does anyone have any useful links to give an introduction to using it (for use in a scripting with changing destination ip addresses)?
On Sun, Jul 25, 2021 at 08:14:13PM -0000, Fedora Borealis wrote:
I think in addition to the above policy you need a second one to accept all traffic destined to tun+. Put tun+ in a zone, then add that zone the egress-zones set. Make sure this new policy has a higher precedence (lower priority value) than the one above.
Thanks for the insights, I'll try that. Nice that you're bringing in the fix to v0.9.5 :)
I'm not familiar with setting the zone for a tun0 device. Currently the tun0 interface has no zone assigned to it (not even the default).
If nothing is explicitly assigned then the default zone will be used.
I currently run openvpn directly as part of a script so that I can easily change the destination ip address (along with changing the firewall just before hand to allow only that address). I'm not that familiar with using network manager (either gui or client) for openvpn connections. Doing some brief digging I've found that I can set the zone using
nmcli connection modify tun0 connection.zone myzone
but this probably isn't the preferred approach since the tun0 device only lasts within the openvpn session.
I don't know if NM will track it across restarts.
Alternatively you can use addresses instead of interfaces names. e.g.
# firewall-cmd --permanent --zone <zone> --add-source 10.0.0.0/8
Use the block of addresses assigned to tun+.
Should I just delve into using network manager proper for the openvpn client connections, saving the configuration (and zone setting)? Does anyone have any useful links to give an introduction to using it (for use in a scripting with changing destination ip addresses)?
I do not have an examples for this.
firewalld-users@lists.fedorahosted.org
-
Eric Garver -
Fedora Borealis