Hi Jozsef,
On Fri, 17 Aug 2018 22:47:56 +0200 (CEST)
Jozsef Kadlecsik <kadlec@xxxxxxxxxxxxxxxxx> wrote:
> Hi,
>
> On Fri, 17 Aug 2018, Stefano Brivio wrote:
>
> > There doesn't seem to be any reason to restrict MAC address
> > matching to source MAC addresses in set types bitmap:ipmac,
> > hash:ipmac and hash:mac. With this patch, and this setup:
> >
> > ip netns add A
> > ip link add veth1 type veth peer name veth2 netns A
> > ip addr add 192.0.2.1/24 dev veth1
> > ip -net A addr add 192.0.2.2/24 dev veth2
> > ip link set veth1 up
> > ip -net A link set veth2 up
> >
> > ip netns exec A ipset create test hash:mac
> > dst=$(ip netns exec A cat /sys/class/net/veth2/address)
> > ip netns exec A ipset add test ${dst}
> > ip netns exec A iptables -P INPUT DROP
> > ip netns exec A iptables -I INPUT -m set --match-set test dst -j ACCEPT
> >
> > ipset will match packets based on destination MAC address:
> >
> > # ping -c1 192.0.2.2 >/dev/null
> > # echo $?
> > 0
>
> The netfilter framework "does not see" the destination MAC address. So how
> does it come that it can get the required information now?
Well, on the receive path, the L2 header is available and complete. On
the sending path, it's not, but there the MAC address is all zeroes and
no packets will match.
Let's say I use the same setup as above, then:
# echo 1 > /proc/sys/net/netfilter/nf_log_all_netns
# ip netns exec A iptables -A INPUT -j LOG --log-prefix "input: "
# ip netns exec A iptables -A OUTPUT -j LOG --log-prefix "output: "
# ping -c1 192.0.2.2 >/dev/null
What I get in the log is:
input: IN=veth2 OUT= MAC=62:68:5a:00:71:7c:72:59:6b:0e:9b:dc:08:00 SRC=192.0.2.1 DST=192.0.2.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=39182 DF PROTO=ICMP TYPE=8 CODE=0 ID=3637 SEQ=1
output: IN= OUT=veth2 SRC=192.0.2.2 DST=192.0.2.1 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=1307 PROTO=ICMP TYPE=0 CODE=0 ID=3637 SEQ=1
I see two issues with the current behaviour:
- we seem to allow but silently disregard matching on destination for sets
using MAC addresses
- we don't allow matching on destination MAC addresses in cases where
the user is legitimately expecting it to work (that is, receive path)
If you think getting destination MAC address matches to work on
selected paths might be confusing to the user, as they might expect it
to work everywhere (e.g. expecting it to match the MAC address of the
destination IP address after routing), I'd rather add a note to the man
page of ipset. I actually don't think it's the case, though.
--
Stefano
