ipfw matches and reports the incorrect interface for IPv6 traffic via the loopback interface. E.g. > 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 (the in via em0 should be in via lo0). Fix: Suggested by Julian Elischer: lo0 is not marking ipv6 packets. How-To-Repeat: 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 > 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. It also indicates that em0 is not used: if both lo0 and em0 would be used, the smaller MTU of em0 would block larger packets, and this is not the case. Hence, em0 seems not used all, despite the reporting of ipfw.
Responsible Changed From-To: freebsd-i386->freebsd-net is a network problem not a 386 problem
Responsible Changed From-To: freebsd-net->freebsd-ipfw fix assignment.
Julian wrongs here. Try the patch please. I've found the superfluous code in nd6.c when wrote a patch for divert(4) and was very annoyed this loopback behaviour. For unknown reasons KAME authors decided to fake interface for loopback. It differs from IPv4 code, so, I guess, it should be fixed. But I could not proof it. Your example is better for this.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
This issue seriousely fails my firewall processing. Since review D3868 did not get acceptance, and, as I might assume, Sergey's patch above might suffer the same problem (linklocal scopes not handled), I went for a different fix, as attached, that appears to work for me.
Created attachment 230537 [details] see coment #5
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
Triage: * add keywords * avoid summary line tags.
^Triage: a) assign to ipfw@ b) remove an incorrect keyword – ipfilter is not ipfw (fault: mine).