IPFW FreeBSD 11 and ipfw table

[dkunets]

We have rules file (/etc/rules):

table 1 delete 1.1.1.1
table 1 delete 2.2.2.2
table 1 add 3.3.3.3

In FreeBSD 10.x run:
ipfw -q /etc/rules
All ok, and run
ipfw table 1 list
returns:

3.3.3.3/32 0

All work fine

In FreeBSD 11.0-RELEASE-p3
ipfw -q /etc/rules
returns:

notfound: 1.1.1.1/32 0
Line 1: Deleting record failed: record not found

And
ipfw table 1 list
returns:

ipfw: failed to request table info: No such process

Ok. Change the file for FreeBSD 11 (/etc/rules):

 table 1 create
table 1 delete 1.1.1.1
table 1 delete 2.2.2.2
table 1 add 3.3.3.3

ipfw -q /etc/rules
returns:

notfound: 1.1.1.1/32 0
Line 2: Deleting record failed: record not found

And
ipfw table 1 list
returns:

ipfw table 1 list
--- table(1), set(0) ---

Returns empty table

ipfw(8)

     -q      Be quiet when executing the add, nat, zero, resetlog or flush
             commands; (implies -f).  This is useful when updating rulesets by
             executing multiple ipfw commands in a script (e.g.,
             `sh /etc/rc.firewall'), or by processing a file with many ipfw
             rules across a remote login session.  It also stops a table add
             or delete from failing if the entry already exists or is not
             present.

             The reason why this option may be important is that for some of
             these actions, ipfw may print a message; if the action results in
             blocking the traffic to the remote client, the remote login
             session will be closed and the rest of the ruleset will not be
             processed.  Access to the console would then be required to
             recover.

In FreeBSD 11 -q key does not work?

 

[obsigna]

I suggest to submit a bug report.

For the time being, as a workaround, I suggest to move the delete and add rules into two separate rule sets which can be called by two consecutive ipfw commands. And I assume that you need to use only one delete directive for all addresses in order that an error condition of trying to delete a non-existent table entry does not prevent deleting the remaining addresses of the list:

table 1 delete \
1.1.1.1 \
2.2.2.2 \
...

 

[dkunets]

I suggest to submit a bug report.

For the time being, as a workaround, I suggest to move the delete and add rules into two separate rule sets which can be called by two consecutive ipfw commands. And I assume that you need to use only one delete directive for all addresses in order that an error condition of trying to delete a non-existent table entry does not prevent deleting the remaining addresses of the list:

table 1 delete \
1.1.1.1 \
2.2.2.2 \
...

So

table 1 create
table 1 delete 1.1.1.1 2.2.2.2
table 1 add 3.3.3.3

ipfw -q /etc/rules

ipfw -q /test
notfound: 1.1.1.1/32 0
notfound: 2.2.2.2/32 0
Line 2: Deleting record failed: record not found

After the error in the 2 line stops execution and table 1 empty

Temporary solution:

ipfw -q table 1 create
ipfw -q table 1 delete 1.1.1.1
ipfw -q table 1 delete 2.2.2.2
ipfw -q table 1 add 3.3.3.3

sh /etc/rules

notfound: 1.1.1.1/32 0
ipfw: Deleting record failed: record not found
notfound: 2.2.2.2/32 0
ipfw: Deleting record failed: record not found

ipfw table 1 list

--- table(1), set(0) ---
3.3.3.3/32 0

It works, but -q not work (when the error displays -> ipfw: Deleting record failed: record not found)

I will write in a bug report.

 

[obsigna]

So

table 1 create
table 1 delete 1.1.1.1 2.2.2.2
table 1 add 3.3.3.3

Not exactly, I suggested:

/etc/delete-rule

table 1 delete 1.1.1.1 2.2.2.2 ...

/etc/add-rule

table 1 add 3.3.3.3 ...

ipfw -q table 1 create; ipfw -q /etc/delete-rule; ipfw -q /etc/add-rule

 

[NuLL3rr0r]

It looks like this also affects security/sshguard-ipfw:

$ service sshguard start
ipfw: failed to request table info: No such process
Could not initialize firewall

sshguard works on FreeBSD 10.3 but it won't work on 11-Release.

 

[NuLL3rr0r]

Well, as suggested here, this solved the issue for me:

$ /sbin/ipfw -q table 22 create

I have to run this before starting security/sshguard.