Ipfw2?
- Ersteller I.MC
- Erstellt am
qfat
Well-Known Member
das ist wieder die alte frage die keiner beantworten kann!
entweder die syntax sagt dir zu oder nicht!
die firewall ist nur so gut wie der der sie gemacht hat.
schau dir die ipfw, ipf und pf an und entscheide selber.
vergleiche features die du brauchst und die syntax.
nimm was sich gut "anfühlt"
entweder die syntax sagt dir zu oder nicht!
die firewall ist nur so gut wie der der sie gemacht hat.
schau dir die ipfw, ipf und pf an und entscheide selber.
vergleiche features die du brauchst und die syntax.
nimm was sich gut "anfühlt"
Ich hatte ipfw und habe seit langem ipf. Ich würde mich nur mal für die Unterschiede zwischen ipfw und ipfw2 interessieren, denn unter ipf steht mir kein traffic shaping zur Verfügung, ipfw mag ich nicht.
Daher habe ich nun zwei Möglichkeiten.
1) Warten bis 5.x stable wird und router dann darauf umstellen. Dann steht mir pf mit ALTQ zur Verfügung.
2) Oder ipfw2 ist toller (für mich) als ipfw
Also irgendeine Doku dazu würde mich daher interessieren.
Gruß, incmc
Daher habe ich nun zwei Möglichkeiten.
1) Warten bis 5.x stable wird und router dann darauf umstellen. Dann steht mir pf mit ALTQ zur Verfügung.
2) Oder ipfw2 ist toller (für mich) als ipfw
Also irgendeine Doku dazu würde mich daher interessieren.
Gruß, incmc
qfat
Well-Known Member
also ne gegenüberstellung hab ich auch net gefunden.
aber lies einfach man ipfw und man ipf durch.
pf müsstest wenn du nicht current hast aus den ports installen.
also der größte unterschied zwischen ipfw und ipf ist das ipfw nur solange für jedes paket sucht bis eine regel gefunden wurde sind also 2 regeln vorhanden wir die 2. nicht bemerkt! und bei ipf wird nur die letzte regel die zutrifft verwendet.
mehr weiß ich auch net.
mir hat ipfw einfach mehr zugesagt.
aber wie oben geschrieben ds ist gefühlssache
aber lies einfach man ipfw und man ipf durch.
pf müsstest wenn du nicht current hast aus den ports installen.
also der größte unterschied zwischen ipfw und ipf ist das ipfw nur solange für jedes paket sucht bis eine regel gefunden wurde sind also 2 regeln vorhanden wir die 2. nicht bemerkt! und bei ipf wird nur die letzte regel die zutrifft verwendet.
mehr weiß ich auch net.
mir hat ipfw einfach mehr zugesagt.
aber wie oben geschrieben ds ist gefühlssache
k33n
knochenbrecher
ein unterschied ist:
net.inet.ip.fw.autoinc_step:
da kann man einstellen mit welchen schritten die regeln hochgezählt werden....
und das:
IPFW2 ENHANCEMENTS
This Section lists the features that have been introduced in ipfw2 which
were not present in ipfw1. We list them in order of the potential impact
that they can have in writing your rulesets. You might want to consider
using these features in order to write your rulesets in a more efficient
way.
Syntax and flags
ipfw1 does not support the -n flag (only test syntax), nor it
allows spaces after commas or supports all rule fields in a sin-
gle argument.
Handling of non-IPv4 packets
ipfw1 will silently accept all non-IPv4 packets (which ipfw1 will
only see when net.link.ether.bridge_ipfw=1). ipfw2 will filter
all packets (including non-IPv4 ones) according to the ruleset.
To achieve the same behaviour as ipfw1 you can use the following
as the very first rule in your ruleset:
ipfw add 1 allow layer2 not mac-type ip
The layer2 option might seem redundant, but it is necessary --
packets passed to the firewall from layer3 will not have a MAC
header, so the mac-type ip pattern will always fail on them, and
the not operator will make this rule into a pass-all.
Addresses
ipfw1 does not supports address sets or lists of addresses.
Port specifications
ipfw1 only allows one port range when specifying TCP and UDP
ports, and is limited to 10 entries instead of the 15 allowed by
ipfw2. Also, in ipfw1 you can only specify ports when the rule
is requesting tcp or udp packets. With ipfw2 you can put port
specifications in rules matching all packets, and the match will
be attempted only on those packets carrying protocols which
include port identifiers.
Finally, ipfw1 allowed the first port entry to be specified as
port:mask where mask can be an arbitrary 16-bit mask. This syn-
tax is of questionable usefulness and it is not supported anymore
in ipfw2.
Or-blocks
ipfw1 does not support Or-blocks.
keepalives
ipfw1 does not generate keepalives for stateful sessions. As a
consequence, it might cause idle sessions to drop because the
byte 63295IPFW2 ENHANCEMENTS
This Section lists the features that have been introduced in ipfw2 which
were not present in ipfw1. We list them in order of the potential impact
that they can have in writing your rulesets. You might want to consider
using these features in order to write your rulesets in a more efficient
way.
Syntax and flags
ipfw1 does not support the -n flag (only test syntax), nor it
allows spaces after commas or supports all rule fields in a sin-
gle argument.
Handling of non-IPv4 packets
ipfw1 will silently accept all non-IPv4 packets (which ipfw1 will
only see when net.link.ether.bridge_ipfw=1). ipfw2 will filter
all packets (including non-IPv4 ones) according to the ruleset.
To achieve the same behaviour as ipfw1 you can use the following
as the very first rule in your ruleset:
ipfw add 1 allow layer2 not mac-type ip
The layer2 option might seem redundant, but it is necessary --
packets passed to the firewall from layer3 will not have a MAC
header, so the mac-type ip pattern will always fail on them, and
the not operator will make this rule into a pass-all.
Addresses
ipfw1 does not supports address sets or lists of addresses.
Port specifications
ipfw1 only allows one port range when specifying TCP and UDP
ports, and is limited to 10 entries instead of the 15 allowed by
ipfw2. Also, in ipfw1 you can only specify ports when the rule
is requesting tcp or udp packets. With ipfw2 you can put port
specifications in rules matching all packets, and the match will
be attempted only on those packets carrying protocols which
include port identifiers.
Finally, ipfw1 allowed the first port entry to be specified as
port:mask where mask can be an arbitrary 16-bit mask. This syn-
tax is of questionable usefulness and it is not supported anymore
in ipfw2.
Or-blocks
ipfw1 does not support Or-blocks.
keepalives
ipfw1 does not generate keepalives for stateful sessions. As a
consequence, it might cause idle sessions to drop because the
lifetime of the dynamic rules expires.
Sets of rules
ipfw1 does not implement sets of rules.
MAC header filtering and Layer-2 firewalling.
ipfw1 does not implement filtering on MAC header fields, nor is
it invoked on packets from ether_demux() and
ether_output_frame(). The sysctl variable net.link.ether.ipfw has
no effect there.
Options
In ipfw1, the following options only accept a single value as an
argument:
ipid, iplen, ipttl
The following options are not implemented by ipfw1:
dst-ip, dst-port, layer2, mac, mac-type, src-ip, src-port.
Additionally, the RELENG_4 version of ipfw1 does not implement
the following options:
ipid, iplen, ipprecedence, iptos, ipttl, ipversion, tcpack,
tcpseq, tcpwin.
Dummynet options
The following option for dummynet pipes/queues is not supported:
noerror.
net.inet.ip.fw.autoinc_step:
da kann man einstellen mit welchen schritten die regeln hochgezählt werden....
und das:
IPFW2 ENHANCEMENTS
This Section lists the features that have been introduced in ipfw2 which
were not present in ipfw1. We list them in order of the potential impact
that they can have in writing your rulesets. You might want to consider
using these features in order to write your rulesets in a more efficient
way.
Syntax and flags
ipfw1 does not support the -n flag (only test syntax), nor it
allows spaces after commas or supports all rule fields in a sin-
gle argument.
Handling of non-IPv4 packets
ipfw1 will silently accept all non-IPv4 packets (which ipfw1 will
only see when net.link.ether.bridge_ipfw=1). ipfw2 will filter
all packets (including non-IPv4 ones) according to the ruleset.
To achieve the same behaviour as ipfw1 you can use the following
as the very first rule in your ruleset:
ipfw add 1 allow layer2 not mac-type ip
The layer2 option might seem redundant, but it is necessary --
packets passed to the firewall from layer3 will not have a MAC
header, so the mac-type ip pattern will always fail on them, and
the not operator will make this rule into a pass-all.
Addresses
ipfw1 does not supports address sets or lists of addresses.
Port specifications
ipfw1 only allows one port range when specifying TCP and UDP
ports, and is limited to 10 entries instead of the 15 allowed by
ipfw2. Also, in ipfw1 you can only specify ports when the rule
is requesting tcp or udp packets. With ipfw2 you can put port
specifications in rules matching all packets, and the match will
be attempted only on those packets carrying protocols which
include port identifiers.
Finally, ipfw1 allowed the first port entry to be specified as
port:mask where mask can be an arbitrary 16-bit mask. This syn-
tax is of questionable usefulness and it is not supported anymore
in ipfw2.
Or-blocks
ipfw1 does not support Or-blocks.
keepalives
ipfw1 does not generate keepalives for stateful sessions. As a
consequence, it might cause idle sessions to drop because the
byte 63295IPFW2 ENHANCEMENTS
This Section lists the features that have been introduced in ipfw2 which
were not present in ipfw1. We list them in order of the potential impact
that they can have in writing your rulesets. You might want to consider
using these features in order to write your rulesets in a more efficient
way.
Syntax and flags
ipfw1 does not support the -n flag (only test syntax), nor it
allows spaces after commas or supports all rule fields in a sin-
gle argument.
Handling of non-IPv4 packets
ipfw1 will silently accept all non-IPv4 packets (which ipfw1 will
only see when net.link.ether.bridge_ipfw=1). ipfw2 will filter
all packets (including non-IPv4 ones) according to the ruleset.
To achieve the same behaviour as ipfw1 you can use the following
as the very first rule in your ruleset:
ipfw add 1 allow layer2 not mac-type ip
The layer2 option might seem redundant, but it is necessary --
packets passed to the firewall from layer3 will not have a MAC
header, so the mac-type ip pattern will always fail on them, and
the not operator will make this rule into a pass-all.
Addresses
ipfw1 does not supports address sets or lists of addresses.
Port specifications
ipfw1 only allows one port range when specifying TCP and UDP
ports, and is limited to 10 entries instead of the 15 allowed by
ipfw2. Also, in ipfw1 you can only specify ports when the rule
is requesting tcp or udp packets. With ipfw2 you can put port
specifications in rules matching all packets, and the match will
be attempted only on those packets carrying protocols which
include port identifiers.
Finally, ipfw1 allowed the first port entry to be specified as
port:mask where mask can be an arbitrary 16-bit mask. This syn-
tax is of questionable usefulness and it is not supported anymore
in ipfw2.
Or-blocks
ipfw1 does not support Or-blocks.
keepalives
ipfw1 does not generate keepalives for stateful sessions. As a
consequence, it might cause idle sessions to drop because the
lifetime of the dynamic rules expires.
Sets of rules
ipfw1 does not implement sets of rules.
MAC header filtering and Layer-2 firewalling.
ipfw1 does not implement filtering on MAC header fields, nor is
it invoked on packets from ether_demux() and
ether_output_frame(). The sysctl variable net.link.ether.ipfw has
no effect there.
Options
In ipfw1, the following options only accept a single value as an
argument:
ipid, iplen, ipttl
The following options are not implemented by ipfw1:
dst-ip, dst-port, layer2, mac, mac-type, src-ip, src-port.
Additionally, the RELENG_4 version of ipfw1 does not implement
the following options:
ipid, iplen, ipprecedence, iptos, ipttl, ipversion, tcpack,
tcpseq, tcpwin.
Dummynet options
The following option for dummynet pipes/queues is not supported:
noerror.
Zuletzt bearbeitet: