Go to main content

man pages section 7: Standards, Environments, Macros, Character Sets, and Miscellany

Exit Print View

Updated: Wednesday, August 8, 2018
 
 

ipf2pf (7)

Name

ipf2pf - migrating from IPF to PF

Description

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.

SERVICE

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.

DIFFERENCES TO IPF

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:

ipf.conf, ipf6.conf

Policy rules for IPv4/IPv6

ipnat.conf

NAT rules

ippool.conf

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.

Attributes

See attributes(7) for descriptions of the following attributes:

ATTRIBUTE TYPE
ATTRIBUTE VALUE
Interface Stability
Volatile

See Also

firewall(7), pf.conf(7), pfctl(8), smf(7), attributes(7)

Securing the Network in Oracle Solaris 11.4