You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the current default for NETWORK_DEVICES, --disallow can only be used before starting vpn. It does not currently fit with the explanation in the manpage since by default it blocks the currently active interface (tun0 if vpn is running, blocking vpn). The same applies to --allow. Not only must it be run after vpn is off, it must be run with the same interface active (e.g. wifi or ethernet) or it will fail to unblock what was previously blocked.
I tried to address this in #25. It's probably not the best default behaviour, but it behaves consistently. When I use vpn, I want everything else to be blocked. I admittedly don't know really anything about docker or libvirt, but I think it's worth noting that the user only needs to change NETWORK_DEVICES to avoid the behaviour. Docker devices seem to be named consistently (docker) and could be easily ignored. Alternatively, we could try to only block the wifi and ethernet device.
If you don't like this idea at all for the default, how about grepping for state UP from ip link and taking the first match? This still may not allow the device that was blocked, but it will never give tun0 and will instead give the wifi or ethernet device. Maybe we could save the blocked device for the --allow?
The text was updated successfully, but these errors were encountered:
Actually, I'm wondering why we're doing it this way in the first place. Is the vpn device always guaranteed to be tun? Does denying out by default and only allowing in on tun not always work? This seems to work for me (e.g. if openvpn is killed):
$ ufw default deny outgoing
# no connection until running following:
$ ufw allow out on tun0
We could save the user's ufws defaults and set them back in the allow (or have a configuration option for the defaults). If there isn't a glaring flaw I've missed, I think this would be a much more reliable way to block non-vpn traffic. It would also remove the need for NETWORK_DEVICES (unless to reverse the purpose to have a list of devices to also allow?).
noctuid
changed the title
Default NETWORK_DEVICES is Semi-Broken
For --deny, Deny Outgoing Traffic By Default?
Sep 3, 2015
EDIT: See the post below first.
With the current default for NETWORK_DEVICES,
--disallow
can only be used before starting vpn. It does not currently fit with the explanation in the manpage since by default it blocks the currently active interface (tun0 if vpn is running, blocking vpn). The same applies to--allow
. Not only must it be run after vpn is off, it must be run with the same interface active (e.g. wifi or ethernet) or it will fail to unblock what was previously blocked.I tried to address this in #25. It's probably not the best default behaviour, but it behaves consistently. When I use vpn, I want everything else to be blocked. I admittedly don't know really anything about docker or libvirt, but I think it's worth noting that the user only needs to change NETWORK_DEVICES to avoid the behaviour. Docker devices seem to be named consistently (docker) and could be easily ignored. Alternatively, we could try to only block the wifi and ethernet device.
If you don't like this idea at all for the default, how about grepping for
state UP
fromip link
and taking the first match? This still may not allow the device that was blocked, but it will never give tun0 and will instead give the wifi or ethernet device. Maybe we could save the blocked device for the--allow
?The text was updated successfully, but these errors were encountered: