mirror of
git://git.proxmox.com/git/pve-firewall.git
synced 2025-01-10 05:18:03 +03:00
97 lines
2.1 KiB
Plaintext
97 lines
2.1 KiB
Plaintext
Experimental software, only used for testing!
|
|
=============================================
|
|
|
|
|
|
Quick Intro
|
|
===========
|
|
|
|
VM firewall rules are read from:
|
|
|
|
/etc/pve/firewall/<VMID>.fw
|
|
|
|
Cluster wide rules and security group are read from:
|
|
|
|
/etc/pve/firewall/cluster.fw
|
|
|
|
Host firewall rules are read from:
|
|
|
|
/etc/pve/local/host.fw
|
|
|
|
You can find examples in the example/ dir
|
|
|
|
|
|
Use the following command to mange the firewall:
|
|
|
|
To test the firewall configuration:
|
|
|
|
./pvefw compile
|
|
|
|
To start or update the firewall:
|
|
|
|
./pvefw start
|
|
|
|
To update the firewall rules (the firewall is not started if it
|
|
is not already running):
|
|
|
|
./pvefw update
|
|
|
|
To stop the firewall:
|
|
|
|
./pvefw stop
|
|
|
|
|
|
Implementation details
|
|
======================
|
|
|
|
We write iptables rules directly, an generate the following chains
|
|
as entry points in the 'forward' table:
|
|
|
|
PVEFW-INPUT
|
|
PVEFW-OUTPUT
|
|
PVEFW-FORWARD
|
|
|
|
We do not touch other (user defined) chains.
|
|
|
|
Each VM can have its own firewall definition file in
|
|
|
|
/etc/pve/firewall/<VMID>.fw
|
|
|
|
That file has a section [RULES] to define firewall rules.
|
|
|
|
Format is: TYPE ACTION IFACE SOURCE DEST PROTO D-PORT S-PORT
|
|
|
|
* TYPE: IN|OUT|GROUP
|
|
* ACTION: action or macro
|
|
* IFACE: vm network interface (net0 - net5), or '-' for all interfaces
|
|
* SOURCE: source IP address, or '-' for any source
|
|
* DEST: dest IP address, or '-' for any destination address
|
|
* PROTO: see /etc/protocols
|
|
* D-PORT: destination port
|
|
* S-PORT: source port
|
|
|
|
A rule for inbound traffic looks like this:
|
|
|
|
IN SSH(ACCEPT) net0
|
|
|
|
Outbound rules looks like:
|
|
|
|
OUT SSH(ACCEPT)
|
|
|
|
Problems
|
|
===================
|
|
|
|
There are a number of restrictions when using iptables to filter
|
|
bridged traffic. The physdev match feature does not work correctly
|
|
when traffic is routed from host to bridge:
|
|
|
|
* when a packet being sent through a bridge entered the firewall on
|
|
another interface and was being forwarded to the bridge.
|
|
|
|
* when a packet originating on the firewall itself is being sent through
|
|
a bridge.
|
|
|
|
We use a second bridge for each interface to avoid above problem.
|
|
|
|
eth0-->vmbr0<--tapXiY (non firewalled tap)
|
|
<--linkXiY-->linkXiYp-->fwbrXiY-->tapXiY (firewalled tap)
|