pf on FreeBSD or OpenBSD - any differences?

Are there any differences, in terms of security features and functionalities, between running the pf firewall under FreeBSD and OpenBSD?

Do you think it is better to consider setting up a separate OpenBSD server just to run the pf firewall, or vice versa? And why?
 
ikevinjp said:
Are there any differences, in terms of security features and functionalities, between running the pf firewall under FreeBSD and OpenBSD?
Not really, just remember that the version of PF on FreeBSD 9.0 is from OpenBSD 4.5.

Do you think it is better to consider setting up a separate OpenBSD server just to run the pf firewall, or vice versa? And why?
I wouldn't do that. If only for the simple fact it makes life a lot easier if all your servers run the same OS.
 
ikevinjp said:
Are there any differences, in terms of security features and functionalities, between running the pf firewall under FreeBSD and OpenBSD?

Do you think it is better to consider setting up a separate OpenBSD server just to run the pf firewall, or vice versa? And why?

We have chose PF on OpenBSD at work to protect us from Internet because:
- it handles netflow via pflow(4), this is a missing feature on FreeBSD.
- routing daemons are in OpenBSD base (OpenBGPd), you don't need anything else than the base.
- easy tcp md5 signature between BGP peers.
- that just work and it handles our load without problem (500 Mbits up/down, around 300 000 states) (2 Dell R610 in failover mode).

Carp on FreeBSD looks not so good (there is a rewriting in -CURRENT), but we could expect better performance on FreeBSD (true SMP) (?).

We are very happy with this solution on OpenBSD, that works very well.
The only small problem is the support of OpenBSD release, it is short (only one year). I upgrade the firewall each 6 months and we use the release version - 1.

HTH.
 
I skimmed the article but it talks about the differences between 3.0 and 3.4. Since FreeBSD's PF is version 4.5 you can assume it's in there. A quick glance in pf.conf(5) and:
Code:
SYN PROXY
     By default, pf(4) passes packets that are part of a tcp(4) handshake
     between the endpoints.  The synproxy state option can be used to cause
     pf(4) itself to complete the handshake with the active endpoint, perform
     a handshake with the passive endpoint, and then forward packets between
     the endpoints.

     No packets are sent to the passive endpoint before the active endpoint
     has completed the handshake, hence so-called SYN floods with spoofed
     source addresses will not reach the passive endpoint, as the sender can't
     complete the handshake.

     The proxy is transparent to both endpoints, they each see a single con-
     nection from/to the other endpoint.  pf(4) chooses random initial
     sequence numbers for both handshakes.  Once the handshakes are completed,
     the sequence number modulators (see previous section) are used to trans-
     late further packets of the connection.  synproxy state includes modulate
     state.

     Rules with synproxy will not work if pf(4) operates on a bridge(4).

     Example:

           pass in proto tcp from any to any port www synproxy state
 
Back
Top