Hello, I'm maintaining a VPN server in fedora and I'm wondering whether I'd need to integrate firewalld to that. After reading the information in https://fedoraproject.org/wiki/FirewallD I don't think I'm sure what I'm supposed to do.
There are two issues: 1. Should my service turn on the firewall ports used by the server? As far as I understand, in order for the service to work out of the box I'd need to call firewall-cmd --port to enable the TCP and UDP ports used by the server, possibly from the systemd unit file (are there any hooks for that?).
2. What zone should the server put the clients they connect. Should there be some special vpn zone or should I use one of the existing ones? (none of the existing looks very reasonable for that).
However, what is not apparent to me as a fedora packager is how is that supposed to be handled. Should the package handle any requirements by firewalld (i.e., package is plug and play), or should the package defer the administrator to configure firewalld separately (i.e., package is installed but doesn't work by default). I see that ssh and few other services are enabled by default by firewalld configuration itself, but what about the others?
regards, Nikos
Am 01.08.2014 um 14:27 schrieb Nikos Mavrogiannopoulos:
I'm maintaining a VPN server in fedora and I'm wondering whether I'd need to integrate firewalld to that. After reading the information in https://fedoraproject.org/wiki/FirewallD I don't think I'm sure what I'm supposed to do.
There are two issues:
- Should my service turn on the firewall ports used by the server?
As far as I understand, in order for the service to work out of the box I'd need to call firewall-cmd --port to enable the TCP and UDP ports used by the server, possibly from the systemd unit file (are there any hooks for that?)
please don't do that without asking the user
and *never* do that in the systemd-unit because even if the user decides to close the port you would open it again - that's a no-go
installing whatever service don't mean automatically it is intended to be reachable on any interface and that is independent of the type of service
nobody but the admin / user knows the intention of a installed package and it is bad practice have to close ports
Hello, ----- Original Message -----
I'm maintaining a VPN server in fedora and I'm wondering whether I'd need to integrate firewalld to that. After reading the information in https://fedoraproject.org/wiki/FirewallD I don't think I'm sure what I'm supposed to do.
I’d guess you only need to ensure a firewalld service definition for the VPN server exists.
There are two issues:
- Should my service turn on the firewall ports used by the server?
As far as I understand, in order for the service to work out of the box I'd need to call firewall-cmd --port to enable the TCP and UDP ports used by the server, possibly from the systemd unit file (are there any hooks for that?).
A service manipulating the firewall for itself? Definitely not. Policy is for the administrator to define; applications opening ports for themselves completely redundant to calling bind(). (We can discuss whether it would be appropriate to ship with a configuration that enables the service by default, but a very likely answer is “no”; we don’t enable httpd by default, for example.)
- What zone should the server put the clients they connect. Should
there be some special vpn zone or should I use one of the existing ones? (none of the existing looks very reasonable for that).
How are the clients connected exactly? If the traffic looks like it arrives on a virtual interface, a zone should be assigned to that interface, using the existing system-wide configuration for that interface (/etc/sysconfig/network-scripts/ifcfg*) if at all possible (this might require extra code I don’t know much about).
However, what is not apparent to me as a fedora packager is how is that supposed to be handled. Should the package handle any requirements by firewalld (i.e., package is plug and play), or should the package defer the administrator to configure firewalld separately (i.e., package is installed but doesn't work by default).
Packages should defer to the administrator. (Note that the F21 _Workstation_ product will ship with a different default, and some Cloud images might have yet another. But in both cases the individual packages are not supposed to care.)
I see that ssh and few other services are enabled by default by firewalld configuration itself,
Those are the exceptions from the general default of keeping services disabled. Mirek
On Fri, 2014-08-01 at 08:47 -0400, Miloslav Trmač wrote:
- What zone should the server put the clients they connect. Should
there be some special vpn zone or should I use one of the existing ones? (none of the existing looks very reasonable for that).
How are the clients connected exactly? If the traffic looks like it arrives on a virtual interface, a zone should be assigned to that interface, using the existing system-wide configuration for that interface (/etc/sysconfig/network-scripts/ifcfg*) if at all possible (this might require extra code I don’t know much about).
Correct the traffic arrives on a virtual interface. So as according to the wiki the client should at some point execute "firewall-cmd --zone=myzone --add-interface=tun-client-iface".
The question is what myzone should be. Should it be one of the pre-defined zones, or should a new zone be created by the application and the administrator should be expected to set its properties?
regards, Nikos
----- Original Message -----
On Fri, 2014-08-01 at 08:47 -0400, Miloslav Trmač wrote:
- What zone should the server put the clients they connect. Should
there be some special vpn zone or should I use one of the existing ones? (none of the existing looks very reasonable for that).
How are the clients connected exactly? If the traffic looks like it arrives on a virtual interface, a zone should be assigned to that interface, using the existing system-wide configuration for that interface (/etc/sysconfig/network-scripts/ifcfg*) if at all possible (this might require extra code I don’t know much about).
Correct the traffic arrives on a virtual interface. So as according to the wiki the client should at some point execute "firewall-cmd --zone=myzone --add-interface=tun-client-iface".
I’m not sure about that. The general case is that NetworkManager (or init.d/network) manage interfaces, including that virtual interface, and therefore _NetworkManager_ interprets the ZONE= setting from the interface configuration
----- Original Message -----
----- Original Message -----
On Fri, 2014-08-01 at 08:47 -0400, Miloslav Trmač wrote:
- What zone should the server put the clients they connect. Should
there be some special vpn zone or should I use one of the existing ones? (none of the existing looks very reasonable for that).
How are the clients connected exactly? If the traffic looks like it arrives on a virtual interface, a zone should be assigned to that interface, using the existing system-wide configuration for that interface (/etc/sysconfig/network-scripts/ifcfg*) if at all possible (this might require extra code I don’t know much about).
Correct the traffic arrives on a virtual interface. So as according to the wiki the client should at some point execute "firewall-cmd --zone=myzone --add-interface=tun-client-iface".
I’m not sure about that. The general case is that NetworkManager (or init.d/network) manage interfaces, including that virtual interface, and therefore _NetworkManager_ interprets the ZONE= setting from the interface configuration
… and the client doesn’t execute anything. (The system administrator would set ZONE= in the ifcfg-* file.)
If NetworkManager isn’t touching the virtual interface at all, your VPN server may have to configure the zone for that interface; but it should be as similar to the generic NetworkManager usage as is reasonable. (I’m not sure that having ifcfg-* files not used by NetworkManager at all and used to set ZONE= would be reasonable; at that point having a zone option in the VPN server configuration may make sense.)
And this should be probably similar to how other VPN mechanisms do this—which I’m afraid I don’t know anything about. Mirek