Hi Stefano,
On Mon, 20 Aug 2018, Stefano Brivio wrote:
> > 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.
That's good to know, so there's no need to check in which path the MAC
address is requested.
> 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.
As far as I see, the destination MAC is useful in input path (PREROUTING)
*and* in bridge mode (ebtables) only. (In the non-bridge mode the dest MAC
should be the MAC address of the receiving interface.) So I'd like to see
the clear documentation in the manpage in order to make clear when dst MAC
can be used.
Best regards,
Jozsef
-
E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
