firewall bug or weird behaviour

[Spiros Pap]

Hi all,

I came by some weird behaviour i don't understand and I would like some help.
I have a cluster (5.2) and I have a VM on a node. I am trying to prevent the VM of changing its IP.
I have configured the "ipfilter-net0" ipset and as far as i understand this corresponds to the following rule :
tap101i0-OUT
237 14220 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ! match-set PVEFW-101-ipfilter-net0-v4 src

So, I changed the IP on the VM and I tried to ping it from the internet. It pinged besides that "ipfilter-net0" was configured with the correct IP.
The investigation I did turned out to show that it was the "ctstate RELATED,ESTABLISHED" in "PVEFW-FORWARD" chain that matched, because:
- ICMP for the VM was allowed for the IN
- conntrack created a flow, which then was "automatically" allowed by the generic "ctstate RELATED,ESTABLISHED" before reaching the "ipfilter-net0" rule, way below.

Now the story begins:
I created an IPSET that contains the IP (A.B.W.R) that the VM is supposed to have, with the 'nomatch' clicked. Like this:
Name: PVEFW-101-vm101-ip-v4
Type: hash:net
Revision: 6
Header: family inet hashsize 64 maxelem 64
Size in memory: 408
References: 2
Number of entries: 1
Members:
A.B.W.R nomatch

I created 3 rules in the VM firewall.
- one to drop icmp when coming (IN) from A.B.X.Z and matches the above IPSET
0 0 DROP icmp -- * * A.B.X.Z 0.0.0.0/0 match-set PVEFW-101-vm101-ip-v4 dst
- one to drop everything when it matches (IN) the above IPSET
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set PVEFW-101-vm101-ip-v4 dst
- one to ACCEPT icmp.
1 84 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0

Chain tap101i0-IN (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
0 0 DROP icmp -- * * A.B.X.Z 0.0.0.0/0 match-set PVEFW-101-vm101-ip-v4 dst
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set PVEFW-101-vm101-ip-v4 dst
1 84 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
34 2576 PVEFW-Drop all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 all -- * * 0.0.0.0/0 0.0.0.0/0 /* PVESIG:tKloeKufFuPBDPfrCkBfPSDzhH4 */


The problem is that as you can see above, the first ping i did from host A.B.X.Z to the VM IP which was NOT the one allowed in the IPSET, did not match the first and the second rule and matched the third one, that allowed ICMP to pass (thats why the pkt counter of the rule, says 1).

It seems to be a BUG, or I don't understand the rules. In the latter case I would appreciate an explanation. I believe that the first rule I described, should match, because the icmp packet had source A.B.X.Z and did not have destination A.B.W.R.


Here is the config:
-------------------------
#cat /etc/pve/firewall/101.fw
[OPTIONS]

enable: 1
ipfilter: 1
policy_in: DROP

[IPSET ipfilter-net0] # IP for vm101-A.B.W.R

A.B.W.R

[IPSET vm101-ip]

!A.B.W.R

[RULES]

IN DROP -source A.B.X.Z -dest +vm101-ip -p icmp
IN DROP -dest +vm101-ip
|IN ACCEPT -dest A.B.W.R -p tcp -dport 3389
|IN ACCEPT -dest +ipfilter-net0 -p tcp -dport 5900
|IN ACCEPT -dest +ipfilter-net0 -p tcp -dport 22
|IN ACCEPT -dest +ipfilter-net0 -p tcp -dport 443
|IN ACCEPT -dest +ipfilter-net0 -p tcp -dport 80
IN ACCEPT -p icmp


Regards,
Sp

 

[Spiros Pap]

Hi all,

Since i don't get any answers, i'd like to rephrase the question:

Does the below rule matches any packets with destination address that is *NOT* A.B.W.R?

0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 match-set PVEFW-101-vm101-ip-v4 dst

Name: PVEFW-101-vm101-ip-v4
Type: hash:net
Revision: 6
Header: family inet hashsize 64 maxelem 64
Size in memory: 408
References: 2
Number of entries: 1
Members:
A.B.W.R nomatch

Thanx!
Sp

 

[Spiros Pap]

I guess the answer is that:
"A.B.W.R nomatch"
does not "match anything but A.B.W.R".
It should be:
"A.B.C.0/24 <--- the network that the IP belongs to
A.B.C.R nomatch" <--- the specific IP that should not be dropped

Sp