ip spoof - ipset

[aychprox]

Hi,

I am learning firewall setting on Proxmox and trying to understand ip spoof prevention.

My Firewall scenario is:

LXC IP: 10.60.60.8 (eth0)

Datacenter level: on
Host level: on
Container level: on
IPfilter for container: on

ipfilter-eth0 added for above ip on container level via Proxmox interface.
Firewall rules set accept ping, the IP it is responding to ping

When add another IP 10.60.60.9 (eth0:0) within container, which suppose not respond to ping (since above ip spoofing is set), but it is.

Anything wrong here?
What i suppose to check so that one VM or container only can use the assigned IP?
Does this similar to ip stealing?

 

[dietmar]

ipfilter-eth0 added for above ip on container level via Proxmox interface.

Please use "ipfilter-net0" for LXC (I assume you are on 4.1)

 

[aychprox]

thank you for your respond.

But no luck, even I change to ipfilter-net0, i still can dump in additional IP within the container and it is responding to any connection after add container firewall rules.

here are the host firewall:

Chain veth201i0-IN (1 references)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp spt:bootps dpt:bootpc
ACCEPT icmp -- anywhere anywhere icmp echo-request
PVEFW-Drop all -- anywhere anywhere
DROP all -- anywhere anywhere
all -- anywhere anywhere /* PVESIG:+Wr4sQbKKi/4rahAoJ6CbblAanM */

Chain veth201i0-OUT (1 references)
target prot opt source destination
PVEFW-SET-ACCEPT-MARK udp -- anywhere anywhere [goto] udp spt:bootpc dpt:bootps
DROP all -- anywhere anywhere MAC ! 36:37:61:36:65:65
DROP all -- anywhere anywhere ! match-set PVEFW-201-ipfilter-net0-v4 src
MARK all -- anywhere anywhere MARK and 0x0
PVEFW-SET-ACCEPT-MARK all -- anywhere anywhere [goto]
all -- anywhere anywhere /* PVESIG:sZJlPKY5DvqkbJFXpicCLVu0JMI */

 

[dietmar]

AFAIK the filter only works on level3 (TCP/UDP).

 

[aychprox]

hi,

what do you meant by level3 TCP/UDP?
Switch or within proxmox interface?

 

[dietmar]

what do you meant by level3 TCP/UDP?

It currently does not filter ICMP (ping) traffic.

 

[wbumiller]

ICMP works over IP so an IP filter does affect it. (As far as the firewall is concerend ICMP is a layer 4 protocol, despite it being usually categorized as layer 3...)

What does `ipset list` show? Do any other firewall rules on the container work as expected?

 

[aychprox]

Hi,

I thought it should disable all connection when setup ipset, and only allow any traffic to the assigned IP.
Yes, other firewall rule working fine.
This is what i have::

ipset list
Name: PVEFW-0-management-v6
Type: hash:net
Revision: 6
Header: family inet6 hashsize 64 maxelem 64
Size in memory: 1152
References: 4
Members:

Name: PVEFW-0-management-v4
Type: hash:net
Revision: 6
Header: family inet hashsize 64 maxelem 64
Size in memory: 448
References: 4
Members:
192.168.1.0/24

Name: PVEFW-201-ipfilter-net0-v4
Type: hash:net
Revision: 6
Header: family inet hashsize 64 maxelem 64
Size in memory: 448
References: 1
Members:
10.60.60.8

Name: PVEFW-201-ipfilter-net0-v6
Type: hash:net
Revision: 6
Header: family inet6 hashsize 64 maxelem 64
Size in memory: 1376
References: 1
Members:
fe80::/10 nomatch
fe80::3437:61ff:fe36:6565

 

[wbumiller]

After adding an invalid IP to the container, can the container always reach all outside addresses or just the the host?

Edit: also, try:

# sysctl net.ipv4.conf.all.rp_filter=1

 

[aychprox]

Hi,

Thanks for reply.

net.ipv4.conf.all.rp_filter=1 break the cluster communication. if net.ipv4.conf.all.rp_filter=0 all cluster node reconnected again.

now I realised the IN to OUT traffic is blocked if changed to an IP not belongs to the container (ipfilter-net0 active). but it can responded to external request OUT to IN.

So in this case the ipfilter-net0 is just block traffic from the container to external addresses, am I right?
Thanks again.

 

[wbumiller]

Setting rp_filter=1 should definitely not break cluster communication. It's actually the recommended value and shouldn't break any decent setup. If you need asymmetric routing you can set it to 2, though.
(with 0 it's possible that packets meant for the host get picked up early before going through the forward chain if their route wasn't cached yet, and connection tracking will then allow the connection to continue)

Do you perhaps have a separate management network which isn't correctly separated from the other network?

 

[aychprox]

em ..... I need to confirm again.
but as long as I put rp_filter=1, cluster communication broken.

 

[wbumiller]

So what about 2?