Bug 1065948 - firewalld zone not applied for vpn connections
firewalld zone not applied for vpn connections
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jirka Klimes
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-17 06:22 EST by CircleCode
Modified: 2016-03-29 10:25 EDT (History)
5 users (show)

See Also:
Fixed In Version: NetworkManager-1.0.6-2.fc22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1238124 (view as bug list)
Environment:
Last Closed: 2015-09-04 04:15:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description CircleCode 2014-02-17 06:22:07 EST
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.
Comment 1 CircleCode 2014-02-17 06:43:10 EST
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…
Comment 2 CircleCode 2014-02-17 07:11:39 EST
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
Comment 3 Dan Williams 2014-02-17 11:55:31 EST
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.
Comment 4 Fedora End Of Life 2015-05-29 06:57:05 EDT
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.
Comment 5 Fedora End Of Life 2015-06-29 11:15:31 EDT
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.
Comment 6 Jirka Klimes 2015-07-03 15:58:36 EDT
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
Comment 7 Thomas Haller 2015-07-09 11:45:12 EDT
(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
Comment 8 Jirka Klimes 2015-07-14 06:37:00 EDT
(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

Note You need to log in before you can comment on or make changes to this bug.