ipf2pf - migrating from IPF to PF
Solaris 11.4 ships with network firewall, which is based on OpenBSD Packet Filter. For more information, see the firewall(7) man page. To facilitate transition from IPF to PF the system upgrade installs ipf2pf (pkg:/network/ipf2pf) package. This package handles the system's dependencies on the obsolete IPF package, pkg:/network/ipfilter.
The ipf2pf package installs the svc:/network/ipf2pf SMF service. This service runs only once, at the first boot into a newly upgraded boot environment. The service stores the now obsolete ipfilter configuration in the /var/firewall/legacy.ipf/conf directory.
The ipf2pf service converts the IPF configuration to a PF configuration. The conversion is written to /var/firewall/legacy.ipf/conf/pf.conf. The system administrator should manually verify that the result of the conversion still implements the desired firewall policy before deploying it on the production system. Also keep in mind the upgrade process leaves your system with default firewall configuration, which provides no ACL policy or protection.
IPF rule syntax can be seen as a kind of subset of PF grammar. This can mislead into assuming that the IPF and PF firewalls are the same. They are not same, they are just similar. The first difference to note is PF typically uses one configuration file, while IPF uses up to four configuration files:
Policy rules for IPv4/IPv6
Definitions of radix tables (IP pools), used by policy rules at from/to match options
For more information about how PF configuration works in Oracle Solaris, see the firewall(7) man page.
The following are differences between IPF and PF which might not be immediately obvious.STATEFUL INSPECTION
Unlike IPF the PF pass rules are implicitly stateful. Consider rule:
pass in from any to any
This rule is syntactically correct in both firewalls, however each firewall interprets the rule quite differently. When converting this rule from IPF to PF, one needs the 'no state' option to preserve the IPF firewall policy in PF:
pass in from any to any no state
Also in case of state match, IPF does 'state mangling'. Consider an inbound forwarded packet, which matches rule:
pass in from any to any keep state
The state created by IPF also matches the outbound forwarded packet. PF must add a rule for the outbound forwarded packet:
pass in from any to any pass out from any to any
The impact of this difference is illustrated in the following rule set:
block out all pass in from any to any keep state
These rules above, allow IPF host to forward traffic between remote endpoints. In case of PF no forwarded packets are allowed to leave the PF host, because all outbound packets hit the 'block' rule. No state in PF would cover outbound packets, too. To allow a PF host to forward traffic, one has to change the rules in PF to:
block out all pass in from any to any keep state pass out from !self to any keep state
The outbound rule allow the outbound packet to leave PF host (and create state) as long as it comes from a remote source, not PF host itself.NAT
Unlike PF, the IPF keeps two session tables.
Table for states created by rules
Table for NAT sessions created by nat-rules
In IPF, NAT sessions define how IP addresses and port numbers in packets should be altered. States are created by policy rules, while sessions are created by NAT rules.
PF takes a completely different approach here. PF implements NAT as an optional action (nat-to/rdr-to) to be taken on a matching packet. The information about IP address translation is kept in a state table. Therefore, NAT optional actions cannot be used with rules that don't create state. If a packet is to be translated, it must create state.TUNABLES
IPF uses tunables as parameters to define table sizes and session timeouts. To change a parameter value, the ipf -T option is used. To make the value persistent requires editing the kernel/drv/ipf.conf file. The ipf2pf conversion process does not preserve these tunables as they are irrelevant to PF.
PF comes with its own parameters. The pfctl command is used to tweak those parameters at runtime. To make the change persistent, the parameters are added to the pf.conf file. For more information, see the pfctl(8) and pf.conf(7) man pages.PACKET LOGGING
IPF uses the ipmon daemon to read logged packets from kernel to userland using /dev/ipl device. Oracle Solaris provides PF with capture links for logging packets. For more information, see the dladm(8) man page. The tcpdump command is used to read the packets from kernel.IPPOOLS
Consider using PF tables where IPF rules use ippools.
See attributes(7) for descriptions of the following attributes: