9:03 a.m.
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?
1:37 p.m.
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.
3:14 p.m.
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)?
7:17 a.m.
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.
998
days inactive
999
days old
firewalld-users@lists.fedorahosted.org
3 comments
2 participants
participants (2)
-
Eric Garver -
Fedora Borealis