+[[chapter_pve_firewall]]
ifdef::manvolnum[]
-PVE({manvolnum})
-================
-include::attributes.txt[]
+pve-firewall(8)
+===============
+:pve-toplevel:
NAME
----
pve-firewall - PVE Firewall Daemon
-SYNOPSYS
+SYNOPSIS
--------
include::pve-firewall.8-synopsis.adoc[]
DESCRIPTION
-----------
endif::manvolnum[]
-
ifndef::manvolnum[]
{pve} Firewall
==============
-include::attributes.txt[]
+:pve-toplevel:
endif::manvolnum[]
+ifdef::wiki[]
+:title: Firewall
+endif::wiki[]
-Proxmox VE Firewall provides an easy way to protect your IT
+{pve} Firewall provides an easy way to protect your IT
infrastructure. You can setup firewall rules for all hosts
inside a cluster, or define rules for virtual machines and
containers. Features like firewall macros, security groups, IP sets
-and aliases helps to make that task easier.
+and aliases help to make that task easier.
While all configuration is stored on the cluster file system, the
-`iptables`-based firewall runs on each cluster node, and thus provides
+`iptables`-based firewall service runs on each cluster node, and thus provides
full isolation between virtual machines. The distributed nature of
this system also provides much higher bandwidth than a central
firewall solution.
cluster nodes, and the `pve-firewall` service updates the underlying
`iptables` rules automatically on changes.
-You can configure anything using the GUI (i.e. Datacenter -> Firewall,
-or on a Node -> Firewall), or you can edit the configuration files
+You can configure anything using the GUI (i.e. *Datacenter* -> *Firewall*,
+or on a *Node* -> *Firewall*), or you can edit the configuration files
directly using your preferred editor.
-Firewall configuration files contains sections of key-value
+Firewall configuration files contain sections of key-value
pairs. Lines beginning with a `#` and blank lines are considered
-comments. Sections starts with a header line containing the section
+comments. Sections start with a header line containing the section
name enclosed in `[` and `]`.
+[[pve_firewall_cluster_wide_setup]]
Cluster Wide Setup
~~~~~~~~~~~~~~~~~~
firewall rules to access the GUI from remote.
-Host specific Configuration
+[[pve_firewall_host_specific_configuration]]
+Host Specific Configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Host related configuration is read from:
This sections contains host specific firewall rules.
-
-VM/Container configuration
+[[pve_firewall_vm_container_configuration]]
+VM/Container Configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~
VM firewall configuration is read from:
can selectively enable the firewall for each interface. This is
required in addition to the general firewall `enable` option.
-The firewall requires a special network device setup, so you need to
-restart the VM/container after enabling the firewall on a network
-interface.
-
Firewall Rules
--------------
IN SSH(ACCEPT) -i net0
IN SSH(ACCEPT) -i net0 # a comment
IN SSH(ACCEPT) -i net0 -source 192.168.2.192 # only allow SSH from 192.168.2.192
-IN SSH(ACCEPT) -i net0 -source 10.0.0.1-10.0.0.10 # accept SSH for ip range
-IN SSH(ACCEPT) -i net0 -source 10.0.0.1,10.0.0.2,10.0.0.3 #accept ssh for ip list
+IN SSH(ACCEPT) -i net0 -source 10.0.0.1-10.0.0.10 # accept SSH for IP range
+IN SSH(ACCEPT) -i net0 -source 10.0.0.1,10.0.0.2,10.0.0.3 #accept ssh for IP list
IN SSH(ACCEPT) -i net0 -source +mynetgroup # accept ssh for ipset mynetgroup
IN SSH(ACCEPT) -i net0 -source myserveralias #accept ssh for alias myserveralias
----
+[[pve_firewall_security_groups]]
Security Groups
---------------
GROUP webserver
----
-
+[[pve_firewall_ip_aliases]]
IP Aliases
----------
* inside IP set definitions
* in `source` and `dest` properties of firewall rules
-Standard IP alias `local_network`
+
+Standard IP Alias `local_network`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This alias is automatically defined. Please use the following command
----
# /etc/pve/firewall/cluster.fw
[ALIASES]
-local_network 1.2.3.4 # use the single ip address
+local_network 1.2.3.4 # use the single IP address
----
+[[pve_firewall_ip_sets]]
IP Sets
-------
IN HTTP(ACCEPT) -source +management
+
Standard IP set `management`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This IP set applies only to host firewalls (not VM firewalls). Those
-ips are allowed to do normal management tasks (PVE GUI, VNC, SPICE,
+IPs are allowed to do normal management tasks (PVE GUI, VNC, SPICE,
SSH).
The local cluster network is automatically added to this IP set (alias
Standard IP set `blacklist`
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Traffic from these ips is dropped by every host's and VM's firewall.
+Traffic from these IPs is dropped by every host's and VM's firewall.
----
# /etc/pve/firewall/cluster.fw
----
-[[ipfilter-section]]
+[[pve_firewall_ipfilter_section]]
Standard IP set `ipfilter-net*`
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
be dropped.
For containers with configured IP addresses these sets, if they exist (or are
-activated via the general `IP Filter` option in the VM's firewall's 'options'
+activated via the general `IP Filter` option in the VM's firewall's *options*
tab), implicitly contain the associated IP addresses.
For both virtual machines and containers they also implicitly contain the
# iptables-save
+[[pve_firewall_default_rules]]
+Default firewall rules
+----------------------
+
+The following traffic is filtered by the default firewall configuration:
+
+Datacenter incomming/outgoing DROP/REJECT
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If the input/output policy for the firewall is set to DROP/REJECT, the following
+traffic is still allowed for the host:
+
+* traffic over the loopback interface
+* already established connections
+* traffic using the igmp protocol
+* tcp traffic from management hosts to port 8006 in order to allow access to
+the web interface
+* tcp traffic from management hosts to the port range 5900 to 5999 allowing
+traffic for the VNC web console
+* tcp traffic from management hosts to port 3128 for connections to the SPICE
+proxy
+* tcp traffic from management hosts to port 22 to allow ssh access
+* udp traffic in the cluster network to port 5404 and 5405 for corosync
+* udp multicast traffic in the cluster network
+* icmp traffic type 3,4 or 11
+
+The following traffic is dropped, but not logged even with logging enabled:
+
+* tcp connections with invalid connection state
+* Broad-, multi- and anycast traffic not related to corosync
+* tcp traffic to port 43
+* udp traffic to ports 135 and 445
+* udp traffic to the port range 137 to 139
+* udp traffic form source port 137 to port range 1024 to 65535
+* udp traffic to port 1900
+* tcp traffic to port 135, 139 and 445
+* udp traffic originating from source port 53
+
+The rest of the traffic is dropped/rejected and logged.
+This may vary depending on the additional options enabled in
+*Firewall* -> *Options*, such as NDP, SMURFS and TCP flag filtering.
+
+Please inspect the output of
+
+ # iptables-save
+
+to see the firewall chains and rules active on your system.
+
+VM/CT incomming/outgoing DROP/REJECT
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This drops/rejects all the traffic to the VMs, with some exceptions for DHCP, NDP,
+Router Advertisement, MAC and IP filtering depending on the set configuration.
+The same rules for dropping/rejecting packets are inherited from the datacenter,
+while the exceptions for accepted incomming/outgoing traffic of the host do not
+apply.
+
+Again, please inspect the output of
+
+ # iptables-save
+
+to see in detail the firewall chains and rules active for the VMs/CTs.
+
+Logging of firewall rules
+-------------------------
+
+By default, all logging of traffic filtered by the firewall rules is disabled.
+To enable logging, the `loglevel` for incommig and/or outgoing traffic has to be
+set in *Firewall* -> *Options*. This can be done for the host as well as for the
+VM/CT firewall individually. By this, logging of {PVE}'s standard firewall rules
+is enabled and the output can be observed in *Firewall* -> *Log*.
+Further, only some dropped or rejected packets are logged for the standard rules
+(see xref:pve_firewall_default_rules[default firewall rules]).
+
+`loglevel` does not affect how much of the filtered traffic is logged. It
+changes a `LOGID` appended as prefix to the log output for easier filtering and
+post-processing.
+
+`loglevel` is one of the following flags:
+
+[[pve_firewall_log_levels]]
+[width="25%", options="header"]
+|===================
+| loglevel | LOGID
+| nolog | no log
+| emerg | 0
+| alert | 1
+| crit | 2
+| err | 3
+| warning | 4
+| notice | 5
+| info | 6
+| debug | 7
+|===================
+
+A typical firewall log output looks like this:
+
+----
+VMID LOGID CHAIN TIMESTAMP POLICY: PACKET_DETAILS
+----
+
+In case of the host firewall, `VMID` is equal to 0.
+
+
+Logging of user defined firewall rules
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In order to log packets filtered by user-defined firewall rules, it is possible
+to set a log-level parameter for each rule individually.
+This allows to log in a fine grained manner and independent of the log-level
+defined for the standard rules in *Firewall* -> *Options*.
+
+While the `loglevel` for each individual rule can be defined or changed easily
+in the WebUI during creation or modification of the rule, it is possible to set
+this also via the corresponding `pvesh` API calls.
+
+Further, the log-level can also be set via the firewall configuration file by
+appending a `-log <loglevel>` to the selected rule (see
+xref:pve_firewall_log_levels[possible log-levels]).
+
+For example, the following two are ident:
+
+----
+IN REJECT -p icmp -log nolog
+IN REJECT -p icmp
+----
+
+whereas
+
+----
+IN REJECT -p icmp -log debug
+----
+
+produces a log output flagged with the `debug` level.
+
Tips and Tricks
---------------
----
-Avoiding `link-local` Addresses on `tap` and `veth` Devices
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-With IPv6 enabled by default every interface gets a MAC-derived link local
-address. However, most devices on a typical {pve} setup are connected to a
-bridge and so the bridge is the only interface which really needs one.
-
-To disable a link local address on an interface you can set the interface's
-`disable_ipv6` sysconf variable. Despite the name, this does not prevent IPv6
-traffic from passing through the interface when routing or bridging, so the
-only noticeable effect will be the removal of the link local address.
-
-The easiest method of achieving this setting for all newly started VMs is to
-set it for the `default` interface configuration and enabling it explicitly on
-the interfaces which need it. This is also the case for other settings such as
-`forwarding`, `accept_ra` or `autoconf`.
-
-Here's a possible setup:
-----
-# /etc/sysconf.d/90-ipv6.conf
-
-net.ipv6.conf.default.forwarding = 0
-net.ipv6.conf.default.proxy_ndp = 0
-net.ipv6.conf.default.autoconf = 0
-net.ipv6.conf.default.disable_ipv6 = 1
-net.ipv6.conf.default.accept_ra = 0
-
-net.ipv6.conf.lo.disable_ipv6 = 0
-----
-
-----
-# /etc/network/interfaces
-(...)
-# Dual stack:
-iface vmbr0 inet static
- address 1.2.3.4
- netmask 255.255.255.128
- gateway 1.2.3.5
-iface vmbr0 inet6 static
- address fc00::31
- netmask 16
- gateway fc00::1
- accept_ra 0
- pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6
-
-# With IPv6-only 'pre-up' is too early and 'up' is too late.
-# Work around this by creating the bridge manually
-iface vmbr1 inet manual
- pre-up ip link add $IFACE type bridge
- up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6
-iface vmbr1 inet6 static
- address fc00:b:3::1
- netmask 96
- bridge_ports none
- bridge_stp off
- bridge_fd 0
- bridge_vlan_aware yes
- accept_ra 0
-(...)
-----
-
-
Notes on IPv6
-------------
level to allow neighbor discovery (NDP) packets to be sent and received.
Beside neighbor discovery NDP is also used for a couple of other things, like
-autoconfiguration and advertising routers.
+auto-configuration and advertising routers.
By default VMs are allowed to send out router solicitation messages (to query
-for a router), and to receive router advetisement packets. This allows them to
+for a router), and to receive router advertisement packets. This allows them to
use stateless auto configuration. On the other hand VMs cannot advertise
themselves as routers unless the ``Allow Router Advertisement'' (`radv: 1`) option
is set.
(`ipfilter: 1`) option which can be enabled which has the same effect as adding
an `ipfilter-net*` ipset for each of the VM's network interfaces containing the
corresponding link local addresses. (See the
-<<ipfilter-section,Standard IP set `ipfilter-net*`>> section for details.)
+<<pve_firewall_ipfilter_section,Standard IP set `ipfilter-net*`>> section for details.)
-Ports used by Proxmox VE
-------------------------
+Ports used by {pve}
+-------------------
* Web interface: 8006
* VNC Web console: 5900-5999
* SPICE proxy: 3128
* sshd (used for cluster actions): 22
* rpcbind: 111
-* corosync multicast (if you run a cluster): 5404, 5405 UDP
+* corosync multicast (if you run a cluster): 5404, 5405 UDP
ifdef::manvolnum[]
projects / pve-docs.git / blobdiff