Local IPv6 traffic not send over loopback?
Freek Dijkstra
public at macfreek.nl
Tue Feb 14 22:02:29 UTC 2012
Hi,
I added a few rules to my firewall to prevent spoofing source IP
addresses. I encountered some (to me) unexpected behaviour where IPv6
traffic originating at the host would match an ipfw rule with "in" and
"recv <interface>" set.
I very much appreciate it if someone could replicate the following
behaviour, and report the results.
1. Add a firewall rule:
"count log ipv6 from me to me not recv lo0"
2. On the host, ping6 to one of it's IP addresses.
Here is the result for me:
2001:610:767:4ec1::1 is an IPv6 address of my host. So I would expect
that pinging the IP from host itself would use the loopback interface.
route get confirms this:
% route get -inet6 2001:610:767:4ec1::1
route to: 2001:610:767:4ec1::1
destination: 2001:610:767:4ec1::1
interface: lo0
flags: <UP,HOST,DONE,STATIC>
recvpipe sendpipe ssthresh rtt,msec mtu weight expire
0 0 0 0 16384 1 0
However, ipfw thinks the traffic is received through another interface:
% ipfw add 1200 count log ipv6 from me to me not recv lo0
% ipfw add 1201 count log ipv6 from me to me out not recv lo0
% ipfw add 1202 count log ipv6 from me to me in not recv lo0
% ping6 -c 1 2001:610:767:4ec1::1
> ipfw: 1200 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em3
> ipfw: 1202 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em3
To add to the confusion, if I would ping the host from an external
machine, the return traffic (ICMPv6:129 is the echo reply) would match a
"recv" interface as well, even though the ICMP packet originated from
the local machine:
% ipfw add 1790 $actfake ipv6 from 2001:610:767::0/48 to any recv tun0
> ipfw: 1790 Deny ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:108:2003:9159:9f48:e2c8:196a] out via tun0
IPv4 traffic behaves as I expect (traffic from me to me uses the
loopback interface; outgoing ICMP does not match a "recv" rule.)
I did not expect this result.
1. Could you replicate this behaviour?
2. Is this intended behaviour?
3. Is this a property of ipfw or the kernel? (e.g. should I report this
here or on freebsd-net?)
Thanks,
Freek
More information about the freebsd-ipfw
mailing list