IPFW using tables to replace ipset

[Chris McVittie]

Hi,
I'm currently trying to migrate from ipset(+iptables) on Linux to ipfw(8) on FreeBSD.

I've a couple of complex parts that I'm struggling with.

1. I've a set of (IP,port) pairs, with a /16 network, e.g. 10.5.10.5,1232. The set contains about 3000 pairs. There is then a forward rule IP is the src-addr, and the port is the dst-port.
(The dst-port is then nat-ed to another dst-addr, but that bit comes in q2). I've seen that there are tables ipfw add table 1 10.5.10.5 1232 and tables have an optional value. But I've been unable to find the syntax to ipfw add allow tcp from 'table(1)' to me 'tablevalue' in. Is this possible? Or should I restructure my rules?

2. Ports in the 1200-1299 range will NAT to a specific server (e.g. 10.100.9.12). I also have a backup server, which I can manually switch to with ipset. ipset swap main-server-12, backup-server-12. I haven't found anything comparable in ipfw, but it's a simple delete and add, so I can make it work. Was just wondering if there is a cleaner way?

Thanks,
Chris

 

[leebrown66]

From ipfw(8), I'd say no, you definitely can't use it with the allow action.

The tablearg feature provides the ability to use a value, looked up in
the table, as the argument for a rule action, action parameter or rule
option. This can significantly reduce number of rules in some configura-
tions. If two tables are used in a rule, the result of the second (des-
tination) is used. The tablearg argument can be used with the following
actions: nat, pipe, queue, divert, tee, netgraph, ngtee, fwd, skipto,
setfib, action parameters: tag, untag, rule options: limit, tagged.

However I'm too new at IPFW myself (like you I'm very familiar with iptables) to make suggestions, they would only guesses at best. Maybe if you could provide a simple example of what you are trying to achieve without the iptables parlance folk here could be of more help. ipset seems to be similar to tables, for example, but folk here are probably not familiar with it.
Sorry I can't be of more help.

 

[SirDice]

Are you set on ipfw(8) or would pf(8) be possible? I don't use IPFW myself but I do use PF. With PF it's easy to create tables and rules for it. Table entries can even be dynamically added or removed without having to reload the firewall. You can even get more control if you use anchors.

 

[obsigna]

...
... ipfw add table 1 10.5.10.5 1232 ...
... ipfw add allow tcp from 'table(1)' to me 'tablevalue' in ...

While the first command line looks OK, the second one looks strange. Try again with:

ipfw add allow tcp from table(1, UINT32_value) to me in.

The description of the Lookup Tables states, that the tablearg parameter can be used for the listed actions, and the allow action is not in that list. This must be a misunderstanding, because the allow action requires a rule body, and the rule body consist of addr parameters which might be a tablearg. So, I would try it anyway.

To your second question, tables could be arguments of the nat action. See the description on the tablearg parameter on https://www.freebsd.org/cgi/man.cgi?query=ipfw&sektion=8#NETWORK ADDRESS TRANSLATION_(NAT), and continue reading on https://www.freebsd.org/cgi/man.cgi?query=ipfw&sektion=8#LOOKUP_TABLES. However, I did not exactly understand what you want to achieve.

 

[wblock@]

Is there a specific reason to choose ipfw(4) and not pf(4)? I switched years ago, and found pf(4) more powerful and easier to use.

 

[leebrown66]

Table entries can even be dynamically added or removed without having to reload the firewall

The same is true of ipfw(4), you don't have to reload anything when you modify a table.

 

[Oko]

Is there a specific reason to choose ipfw(4) and not pf(4)? I switched years ago, and found pf(4) more powerful and easier to use.

I can't believe what you wrote. You know the history of my posts and my background and even I will be first to admit that PF is not more powerful than IPFW even though it might have much simpler syntax. They are two different products. I think for the very high traffic (over 5 Gbit/s) IPFW is probably going to be faster. Having in mind that FreeBSD version of PF is pseudo fork of an obsolete version of PF without certain future I will say that for a dedicated FreeBSD user IPFW is a better choice in particularly for the guy who is moving from IPTables which are based on IPFW. PF on FreeBSD is OK if you are familiar with it from OpenBSD and you don't want to bother with another firewall. Now whether I would chose Free over Open as a firewall solution is a different question and you probably know my answer.

 

[phoenix]

They each have their pros and cons. Neither one is inherently better than the other in every way. Which one a person uses depends on which one they find easier to use.

Some people like the simplicity of the pf.conf syntax, and the ease with which stateful filtering works with PF. Others like the power of dummynet(4) and "plain English" syntax for IPFW rules. Both have their issues; both have their strengths.

Try them both, see which one better suits how you think/work, and use that one.

 

[wblock@]

I can't believe what you wrote.

Letters, words, syllables, punctuation, upper and lower case, everything!

You know the history of my posts and my background and even I will be first to admit that PF is not more powerful than IPFW even though it might have much simpler syntax.

Being able to make it do what is wanted is one aspect of power.

They are two different products.

Well, yes, what with the different names and all.

I think for the very high traffic (over 5 Gbit/s) IPFW is probably going to be faster.

IPFW is known to be a few percent faster. OP did not mention high bandwidth or other use cases, which is why it should be asked if there was a specific need for IPFW.

Having in mind that FreeBSD version of PF is pseudo fork of an obsolete version of PF without certain future

It would be nice to see OpenBSD import the SMP features of FreeBSD's PF, or maybe develop their own if necessary. Then we could import their newer PF, and they'd get SMP support.
The future is not certain, but PF has been in FreeBSD since 2004. It's not going to go away overnight.

I will say that for a dedicated FreeBSD user IPFW is a better choice in particularly for the guy who is moving from IPTables which are based on IPFW.

Or it might be a good time to consider using a firewall that is less difficult to get working. The opportunities to break path dependence are rare, and worth evaluating when the opportunity arises.

PF on FreeBSD is OK if you are familiar with it from OpenBSD and you don't want to bother with another firewall.

At the time I switched, all I had ever used was IPFW on FreeBSD. PF was easier and more powerful. In particular, using NAT was much easier than in IPFW.

 

[Oko]

It would be nice to see OpenBSD import the SMP features of FreeBSD's PF, or maybe develop their own if necessary. Then we could import their newer PF, and they'd get SMP support.

I would expect that FreeBSD developer is better informed about other BSDs. OpenBSD recently hold the whole hackaton dedicated to SMP network work.


http://undeadly.org/cgi?action=article&sid=20151212192918
http://undeadly.org/cgi?action=article&sid=20151218175010

Just install 5.9 Beta to get the taste of what is cooking. For the record Alexander Bluhm is Oracle employee and now OpenBSD developer who imported the latest PF into Solaris 11.3 and part of the team which made it default firewall in Solaris 12.0. There are other exciting news for people who care about OpenBSD but this is not the place.

Why would OpenBSD even consider importing SMP features from FreeBSD? First off I would expect that you as a FreeBSD developer know that SMP changes introduced into PF by FreeBSD crew depend on FreeBSD network layer which is very different than OpenBSD. Secondly I can't believe that you guys don't get this. It is not just about the old syntax. PF has been practically rewritten and so many features have been added since the code was last time imported into FreeBSD. This has been beaten to the death last Summer on the FreeBSD mailing list but somehow people still keep talking about FreeBSD specific SMP "improvements". Even that old IPv6 bugs are in FreeBSD code not to mention lack of queuing and prioritization (ALTQ has never been in generic FreeBSD even thought that was written for FreeBSD but was in Open and now completely replaced by native PF queuing and prioritization layer).

 

[leebrown66]

The description of the Lookup Tables states, that the tablearg parameter can be used for the listed actions, and the allow action is not in that list. This must be a misunderstanding, because the allow action requires a rule body, and the rule body consist of addr parameters which might be a tablearg. So, I would try it anyway.

The documentation is correct, but certainly my bad in confusing the issue. I was confusing table() with tablearg. table() is usable, as you say, as a lookup for addr:, however tablearg is not usable with allow. i.e. you cannot say

allow tablearg from table(1) to any

(implying the protocol is picked from the table based on the IP address), however this is fine.

allow tcp from table(1) to any

I believe what the OP wants to do is (picking random ip's and port #'s) for part 1 is

allow ip from 10.1.2.3 to me src-port 5353 in
allow ip from 10.1.2.4 to me src-port 7654 in
allow ip from 10.4.2.3 to me src-port 875 in

but in table form, which I don't believe your syntax will provide, nor is it possible as it would need to accept

allow ip from table(1) to me src-port tablearg in

but that is not supported either as src-port requires a definitive number, range or list.

table()'s therefore do not correlate to ipsets, except in the simplest of cases, matching IP address/masklen. They each provide capabilities the other does not.

ipsets are far more comprehensive, including the ability to have lists of sets ... but I digress (and apologise for taking us all off on a tangent).

 

[Chris McVittie]

Sorry for the slow reply, I didn't get an email, and forgot to check over the Christmas period.

I've no strong feelings on the ipfw(8) vs pf(4). However, I can't see a way of storing ports in pf(4) table's, so I'm not sure how it helps?

So to summarise my understanding of the discussion, what I'm wanting to do (and can in ipset) doesn't seem possible with either pf(4) or ipfw(8)?

 

[leebrown66]

I don't believe in the same way no.

I'm going to speculate you would have to write 3000 separate rules. If they are fairly static, that's probably not an issue, but if they are dynamic you're going to have more work keeping track so you can dynamically delete and add rules on demand.