A situation has arisen in which ipfw fwd stops working when RTF_BLACKHOLE or RTF_REJECT, ROUTE (8), is enabled on Freebsd 11 release. FreeBSD 11.2-RELEASE-p1 route add default 127.0.0.1 -blackhole –iface ipfw show 00100 30 4056 fwd 10.0.0.5 ip from table(1) to not 10.0.0.0/8 in via em0 The packet counter changes, but forwarding does not work. On FreeBSD 10 everything works fine. I suppose this is due to changes to forwarding -> fast forwarding by default in FreeBSD 11 and man ROUTE (8), “BUGS - unless IP fast forwarding is enabled, in which case the meaning of the flag will always be honored.”
Do you use GENERIC kernel?
Created attachment 196851 [details] proposed fix Please test the patch fixing the problem: fetch it, run "cd /usr/src && patch < /path/to/patch", rebuild and reinstall the kernel, reboot and re-test. It should just work.
Created attachment 196852 [details] proposed fix re-add same patch with proper paths added
Created attachment 196860 [details] proposed fix More correct version of the patch following current mode of packet filtering operation that does not skip second pass over filters if "ipfw fwd" matched incoming packet.
(In reply to Eugene Grosbein from comment #4) Excellent! This patch works for Me. cd /usr/src && patch < /path/to/patch |Index: sys/netinet/ip_fastfwd.c |=================================================================== |--- sys/netinet/ip_fastfwd.c (revision 338011) |+++ sys/netinet/ip_fastfwd.c (working copy) -------------------------- Patching file sys/netinet/ip_fastfwd.c using Plan A... Hunk #1 succeeded at 151. Hunk #2 succeeded at 292. Hunk #3 succeeded at 312. Hunk #4 succeeded at 338. Hunk #5 succeeded at 361. route add default 127.0.0.1 -blackhole -iface Internet: Destination Gateway Flags Netif Expire default 127.0.0.1 USB lo0 traffic from the address from table(1) is forwarded. ipfw show 00100 139 9466 fwd 10.0.0.5 ip from table(1) to not 10.0.0.0/8 in via vtnet0 icmp not from table(1) address, is silently dropped (-blackhole) Many thanks! Great work! Good luck to you!
A commit references this bug: Author: eugen Date: Wed Sep 5 13:59:36 UTC 2018 New revision: 338468 URL: https://svnweb.freebsd.org/changeset/base/338468 Log: Fix "ipfw fwd" to work for incoming IPv4 packets when ip_tryforward() chooses fast forwarding path, as it already works for IPv6 and for both of them on old slow path. PR: 231143 Reviewed by: ae Approved by: re (gjb) MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D17039 Changes: head/sys/netinet/ip_fastfwd.c
A commit references this bug: Author: eugen Date: Wed Sep 12 08:46:50 UTC 2018 New revision: 338611 URL: https://svnweb.freebsd.org/changeset/base/338611 Log: MFC r338468: Fix "ipfw fwd" to work for incoming IPv4 packets when ip_tryforward() chooses fast forwarding path, as it already works for IPv6 and for both of them on old slow path. PR: 231143 Reviewed by: ae Differential Revision: https://reviews.freebsd.org/D17039 Changes: _U stable/11/ stable/11/sys/netinet/ip_fastfwd.c
Committed and merged, thanks for testing. The fix will be present in upcoming 12.0-RELEASE and 11.3-RELEASE.
It seems the fix can be applied to stable/10 too. Probably with small modification.
(In reply to Andrey V. Elsukov from comment #9) ip_tryforward() does not exist in 10.x but it has sysctl net.inet.ip.fastforwarding with default value 0 corresponding to slow path, so it is not affected in default configuration. The change does not apply cleanly to 10.x and I saw no requests to fix fastforwarding for 10.x and ENOTIME. Feel free to patch stable/10, if you wish.