Date: Wed, 15 Feb 2012 14:03:11 -0800 From: Julian Elischer <julian@freebsd.org> To: Freek Dijkstra <public@macfreek.nl> Cc: "Bjoern A. Zeeb" <bz@freebsd.org>, ipfw mailing list <ipfw@freebsd.org> Subject: Re: Local IPv6 traffic not send over loopback? Message-ID: <4F3C2B9F.7020400@freebsd.org> In-Reply-To: <4F3C2739.8070200@macfreek.nl> References: <54ae383d8f680344a2c72f1ed59b366f@mediamonks.com> <4F3C2739.8070200@macfreek.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/15/12 1:44 PM, Freek Dijkstra wrote: > Hi Julian and Terrence, > > Thanks for your tests! > > I'm now convinced there is a bug in ipfw. > > As Terrence and I tested, ipfw is matching rules, and reporting in the > log, that IPv6 traffic between local IPv6 addresses (from me6 to me6) > using an interface other than lo0. > > e.g. > ipfw: 1 Count ICMPv6:128.0 [2001:610:767:1981::1] [2001:610:767:1981::1] > in via em3 > > This was in contrast with "route get", which reported that the traffic > would use lo0. > > So either "route" or ipfw is wrong. By varying the MTU size, I verified > that ping6 traffic from two local IPv6 addresses (not ::1) indeed uses > the lo0 (loopback) interface. Thus not the em3 interface as ipfw is > reporting. > > I can only conclude that this is a bug in ipfw. > Is there a place where I can submit a bug report? > > > While writing down the bug report, I realised that in my previous mail > there were actually two issues: > > 1. ipfw reports that IPv6 traffic from me to me is using a non-loopback > interface. This is unexpected to me, since the traffic really seems to > use the loopback interface lo0, as reported by "route get" and tested by > varying the MTU. > > 2. ICMPv6 replies originating at the pinged host match a rule with the > "recv" pattern. This is unexpected to me, given the line man 8 ipfw: > "packets originating from the local host have no receive interface" > > To separate the two issues, I've included two bug reports below. > > Regards, > Freek > > _ ______________________________________________ > > Report #1: ipfw reports wrong interface for IPv6 loopback traffic > > Summary: > ipfw matches and reports incorrect interface for IPv6 traffic between > through the lookback interface in case the source/destination IP is not ::1. > > Steps to reproduce: > 1. Determine a global IPv6 address of your host. In this report, > 2001:610:767:4ec1::1 is used. > 2. Verify that the routing table has an entry associating this IP > address with the loopback interface. E.g.: > % route get -inet6 2001:610:767:4ec1::1 > route to: 2001:610:767:4ec1::1 > destination: 2001:610:767:4ec1::1 > interface: lo0 > 3. Add the following rules to ipfw: > # ipfw add 1 count log ipv6 from me6 to me6 recv lo0 > # ipfw add 2 count log ipv6 from me6 to me6 not recv lo0 > 4. Run sudo sysctl net.inet.ip.fw.one_pass=0 > 5. Ping the local IP: > % ping6 -c 1 2001:610:767:4ec1::1 > 6. examine the IPFW log file. > > Expected result: > I expected rule 1 to match: >> ipfw: 1 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 >> ipfw: 1 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via lo0 >> ipfw: 1 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 >> ipfw: 1 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via lo0 > Actual result: > Rule 2 matched: >> ipfw: 2 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 >> ipfw: 2 Count ICMPv6:128.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em0 there is the bug: lo0 is not marking ipv6 packets. >> ipfw: 2 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] out via lo0 >> ipfw: 2 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::1] in via em0 > Further analysis: > Adding rules for "xmit lo0" and "not xmit lo0" clearly show that > according to ipfw, the packet is "xmit lo0 recv em0". > > Beside using "route get" in step 2 above, there is another method to > determine the interface that is used by the packet, the MTU size. > By default, the MTU of lo0 is 16384 bytes, and other interface have a > MTU of 1500 bytes: > % ifconfig: > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 > em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > > % ping6 -c 1 -D -s 16336 -b 32000 "2001:610:767:4ec1::1" > works fine > % ping6 -c 1 -D -s 16337 -b 32000 "2001:610:767:4ec1::1" > fails > > Hence, the MTU is 16336 bytes payload + 48 byte overhead = 16384 bytes, > so that indicates the actual interface used is lo0, not em0. > > Since a packet of 16384 bytes comes through, and em0 has a MTU of 1500 > bytes, this also means that em0 is really not used, and the receiving > interface as reported and matched by ipfw is wrong. > > _ ______________________________________________ > > Report #2: ipfw matches recv data for outgoing ICMPv6 replies. > > Summary: > When a host creates an IPv6 reply packets and sends it out, the packet > is matched by a ipfw rule with a "recv" pattern. > > Steps to reproduce: > 1. Determine the IPv6 addresses of two hosts, and make sure they can > ping each other over IPv6. > 2. On one host, add the following rules to ipfw: > # ipfw add 10 count log icmp6 from any to me > # ipfw add 11 count log icmp6 from any to me recv \* > # ipfw add 12 count log icmp6 from any to me xmit \* > # ipfw add 13 count log icmp6 from any to me in recv \* > # ipfw add 14 count log icmp6 from any to me out recv \* > # ipfw add 15 count log icmp6 from any to me out xmit \* > # ipfw add 20 count log icmp6 from me to any > # ipfw add 21 count log icmp6 from me to any recv \* > # ipfw add 22 count log icmp6 from me to any xmit \* > # ipfw add 23 count log icmp6 from me to any in recv \* > # ipfw add 24 count log icmp6 from me to any out recv \* > # ipfw add 25 count log icmp6 from me to any out xmit \* > 3. From the other host, ping the first host (with the ipfw rules), e.g.: > % ping6 -c 1 2001:610:767:4ec1::1 > 4. examine the IPFW log file. > > Expected result: >> ipfw: 10 Count ICMPv6:128.0 [2001:610:767:4ec1::6] [2001:610:767:4ec1::1] in via em3 >> ipfw: 11 Count ICMPv6:128.0 [2001:610:767:4ec1::6] [2001:610:767:4ec1::1] in via em3 >> ipfw: 13 Count ICMPv6:128.0 [2001:610:767:4ec1::6] [2001:610:767:4ec1::1] in via em3 >> ipfw: 20 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out via em3 >> ipfw: 22 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out via em3 >> ipfw: 25 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out via em3 > Actual result: >> ipfw: 10 Count ICMPv6:128.0 [2001:610:767:4ec1::6] [2001:610:767:4ec1::1] in via em3 >> ipfw: 11 Count ICMPv6:128.0 [2001:610:767:4ec1::6] [2001:610:767:4ec1::1] in via em3 >> ipfw: 13 Count ICMPv6:128.0 [2001:610:767:4ec1::6] [2001:610:767:4ec1::1] in via em3 >> ipfw: 20 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out via em3 >> ipfw: 21 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out via em3 >> ipfw: 22 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out via em3 >> ipfw: 24 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out via em3 >> ipfw: 25 Count ICMPv6:129.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out via em3 > Further analysis: > It seem that the outgoing ICMP reply (ICMPv6:129) matches the rules with > "recv" match as well. This is unexpected, as the ICMPv6 reply originates > at the first host, and the man page of ipfw clearly states: "packets > originating from the local host have no receive interface" > > This behaviour only seem to occur with ICMPv6 replies. ICMPv6 requests > work fine, as can be seem from this result to ping host two from host one: > % ping6 -c 1 2001:610:767:4ec1::6 >> ipfw: 20 Count ICMPv6:135.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out via em3 >> ipfw: 22 Count ICMPv6:135.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out via em3 >> ipfw: 25 Count ICMPv6:135.0 [2001:610:767:4ec1::1] [2001:610:767:4ec1::6] out via em3 >> ipfw: 10 Count ICMPv6:136.0 [2001:610:767:4ec1::6] [2001:610:767:4ec1::1] in via em3 >> ipfw: 11 Count ICMPv6:136.0 [2001:610:767:4ec1::6] [2001:610:767:4ec1::1] in via em3 >> ipfw: 13 Count ICMPv6:136.0 [2001:610:767:4ec1::6] [2001:610:767:4ec1::1] in via em3 > Not all incoming traffic is affected. The following excerpt is from a > SSH session that the second host initiates, connecting to the first host: > % ssh -6 2001:610:767:4ec1::1 >> ipfw: 10 Count TCP [2001:610:767:4ec1::6]:55370 [2001:610:767:4ec1::1]:22 in via em3 >> ipfw: 11 Count TCP [2001:610:767:4ec1::6]:55370 [2001:610:767:4ec1::1]:22 in via em3 >> ipfw: 13 Count TCP [2001:610:767:4ec1::6]:55370 [2001:610:767:4ec1::1]:22 in via em3 >> ipfw: 20 Count TCP [2001:610:767:4ec1::1]:22 [2001:610:767:4ec1::6]:55370 out via em3 >> ipfw: 22 Count TCP [2001:610:767:4ec1::1]:22 [2001:610:767:4ec1::6]:55370 out via em3 >> ipfw: 25 Count TCP [2001:610:767:4ec1::1]:22 [2001:610:767:4ec1::6]:55370 out via em3 > I would expect ICMPv6 replies to behave (with regard to matching "recv" > patterns) the same as other packets originating from a host, and never > matches. > > _ ______________________________________________ > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3C2B9F.7020400>