Description of problem: When a vpn connection is associated with a firewalld zone, starting vpn through NetworkManager does not apply the specified zone Version-Release number of selected component: NetworkManager.x86_64 1:0.9.9.0-28.git20131003.fc20 NetworkManager-glib.x86_64 1:0.9.9.0-28.git20131003.fc20 NetworkManager-l2tp.x86_64 0.9.8.5-1.fc20 NetworkManager-openconnect.x86_64 0.9.8.0-2.fc20 NetworkManager-openvpn.x86_64 1:0.9.9.0-0.1.git20140128.fc20 NetworkManager-openvpn-gnome.x86_64 1:0.9.9.0-0.1.git20140128.fc20 NetworkManager-pptp.x86_64 1:0.9.8.2-3.fc20 NetworkManager-pptp-gnome.x86_64 1:0.9.8.2-3.fc20 NetworkManager-vpnc.x86_64 1:0.9.8.2-2.fc20 NetworkManager-vpnc-gnome.x86_64 1:0.9.8.2-2.fc20 How reproducible: always Steps to Reproduce: 1. Set up a VPN in the "work" firewall zone 2. Save the configuration 3. check the zone is correctly set in `/etc/NetworkManager/system-connections/<connection-name>` 4. start the vpn 5. check applied zones with `firewall-cmd --get-active-zones` Actual results: # firewall-cmd --get-active-zones work interfaces: em1 Expected results: # firewall-cmd --get-active-zones work interfaces: em1 tun0 Additional info: Since tun0 is not listed in default zone (Public in my case), I first thought it is simply not listed by `firewall-cmd --get-active-zones` then I tested by changing Public zone configuration (opening ports) and I can confirm tun0 is in Public zone.
as an addition, `nmcli -f NAME,DEVICES,ZONE con status` now throws an error (Error: 'status' is not valid 'connection' command.), and `nmcli -f all con show configured` does not give any information about zone…
nmcli -f NAME,DEVICES,ZONE connection show active lists the connection in the correct zone, but after an irc discussion on nm channel, it appears that this is given by the config while nm_firewall_manager_add_or_change_zone() does not get called for VPNs
Yes, zones are not currently applied to VPN connections, but they should be. There are two cases here: 1) VPN has a tunnel interface; the zone should be applied to the tunnel interface name 2) VPN has no tunnel interface (eg, IPSec): no zone should be applied. Since some traffic still goes over the parent interface and not the VPN routes, we cannot assume that all traffic going over the parent interface is in the VPN's zone. The code to set the FW zone would be put into nm_vpn_connection_config_maybe_complete() in place of immediately calling nm_vpn_connection_apply_config(). See nm-device.c nm_device_activate_schedule_stage3_ip_config_start() for an example. Then, the callback from the firewall manager would check the FW result, and if successful, call nm_vpn_connection_apply_config(). Keep the gpointer that the FW manager returns and use it to call nm_firewall_manager_cancel_call() during VPN connection teardown. Also make sure we set that pointer to NULL when the call is finished or the VPN state is changed, and then have the FW callback check if it's NULL and do nothing. That should ensure that if eg the VPN service quits while the FW manager is doing something that the FW callback doesn't trigger when the VPN connection is already dead.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.
The code is implementing zones for VPN connection is in upstream branch jk/vpn-firewall-zone-rh1065948. Fedora 22 scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=10285514
(In reply to Jirka Klimes from comment #6) > The code is implementing zones for VPN connection is in upstream branch > jk/vpn-firewall-zone-rh1065948. > > Fedora 22 scratch build: > http://koji.fedoraproject.org/koji/taskinfo?taskID=10285514 before calling nm_firewall_manager_add_or_change_zone(), maybe clear priv->fw_call? // FIXME: fail the activation? ^^ /**/ ? Rest LGTM
(In reply to Thomas Haller from comment #7) > (In reply to Jirka Klimes from comment #6) > > The code is implementing zones for VPN connection is in upstream branch > > jk/vpn-firewall-zone-rh1065948. > > > > Fedora 22 scratch build: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=10285514 > > before calling nm_firewall_manager_add_or_change_zone(), maybe clear > priv->fw_call? > Done. > // FIXME: fail the activation? > ^^ /**/ ? > http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/CONTRIBUTING Code pushed to upstream repository: master: a418750 vpn: send firewall zone to firewalld also for VPN connections (rh #1065948) nm-1-0: 0912468 vpn: send firewall zone to firewalld also for VPN connections (rh #1065948