When network is added to the table ipfw in shortened form, network ::/0 appears. By the context of the rules ipfw - drop or reset, network ::/0 can block access to the target machine. In the system 9.0 such behavior was not observed. For example, the network 177.204/14 #whois -L 177.204/14 .. inetnum: 177.204/14 aut-num: AS18881 abuse-c: GOI owner: Global Village Telecom .. How-To-Repeat: #ipfw table 100 list #ipfw table 100 add 177.204/14 #ipfw table 100 list ::/0 0
Responsible Changed From-To: freebsd-bugs->freebsd-ipfw Over to maintainer(s).
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
In system 12.3-STABLE, the behavior of ipfw has changed. If the network is specified in short form, then the first and last ipv4 octet is added with a /32 netmask # uname FreeBSD 12.3-STABLE #0 r372170M: Mon Jun 27 19:29:31 EEST 2022 # ipfw table 10000 list ipfw: failed to request table info: No such process # ipfw table 10000 create # ipfw table 10000 add 177.204/14 added: 177.0.0.204/32 0 # ipfw table 10000 list 177.0.0.204/32 0
(In reply to Vladislav V. Prodan from comment #3) and # ipfw table 10000 add 10/8 added: 0.0.0.10/32 0
(In reply to Vladislav V. Prodan from comment #4) # ipfw table 10000 add 2982936576/16 added: 177.204.0.0/32 0
(In reply to Vladislav V. Prodan from comment #5) See also bug 258874
# ipfw table 10000 add 0/4 error: 0.0.0.0/32 0 ipfw: Adding record failed: Invalid argument # ipfw table 10000 add 0/8 error: 0.0.0.0/32 0 ipfw: Adding record failed: Invalid argument # ipfw table 10000 add 127/8 added: 0.0.0.127/32 0
# ipfw table 10000 add 240/4 added: 0.0.0.240/32 0
(In reply to Vladislav V. Prodan from comment #8) I pointed to bug 258874 only as an explanation. It's not any real bug. Neither is this one IMHO. Classful network notation is deprecated, or at least no more correct. RFC 791 where it was introduced doesn't officially support shortened notation scheme. Relying on this scheme in 2023 and demanding support for an unofficial shortened classful notation for the legacy IP protocol is no more feasible. I have run some tests on 13.1-STABLE for both IP protocols and everything seems to work fine, at least fully consistent with inet (3) man page: # ipfw table 100 add 0.0.0.0/4 added: 0.0.0.0/4 0 # ipfw table 100 add 0.0.0.0/8 added: 0.0.0.0/8 0 # ipfw table 100 add 127.0.0.0/8 added: 127.0.0.0/8 0 # ipfw table 100 add 18 added: 0.0.0.18/32 0 # ipfw table 100 add 18.12 added: 18.0.0.12/32 0 # ipfw table 100 add 18.34.4 added: 18.34.0.4/32 0 # ipfw table 100 add ::1 added: ::1/128 0 # ipfw table 100 add 2001:db8::/32 added: 2001:db8::/32 0 # ipfw table 100 add 2000::/3 added: 2000::/3 0 # ipfw table 100 add 64:ff9b::8.8.8.8 added: 64:ff9b::808:808/128 0 Anyway, it still could be considered a POLA or ABI violation for 12-STABLE if it worked before.