kern/73517: pfil_hooks (ipfw,pf etc) and ipsec processing order for outgoing packets is wrong

Ari Suutari ari at
Thu Nov 4 01:20:27 PST 2004

>Number:         73517
>Category:       kern
>Synopsis:       pfil_hooks (ipfw,pf etc) and ipsec processing order for outgoing packets is wrong
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov 04 09:20:26 GMT 2004
>Originator:     Ari Suutari
>Release:        FreeBSD 5.3-RC2 i386
System: FreeBSD 5.3-RC2 FreeBSD 5.3-RC2 #13: Wed Nov 3 17:47:15 EET 2004 ari at i386

When using IPSEC_FILTERGIF kernel option, the processing order of ipsec and
ipfw (pfil_hook) is not correct for outgoing packets.
Currently, ipsec processing is done first regardsless of IPSEC_FILTERGIF,
which makes packets to go through without firewall inspection.
This might be a security problem for someone, but at least it
breaks stateful rule handling.

My test setup is (all freebsd 5.3-rc1 machines):

freebsd laptop <-> ipsec tunnel <->freebsd server

When server sends packet to laptop, it now goes like this:

ip_output -> ipsec -> ipfw -> network

It should go like this:

ip_output -> ipfw -> ipsec -> ipfw -> network

Compiler kernel with ipsec and IPSEC_FILTERGIF options. Create
ipsec policy, which uses esp between two machines. Add firewall 
rules like

ipfw add count esp from a to b
ipfw add count esp from b to a
ipfw add count icmp from a to b
ipfw add count icmp from b to a

Start pinging from a to b. You'll notice that only one
of the icmp counters increases.

I think that this could be fixed by just moving/adding pfil_hook
processing in ip_output before ipsec processing when IPSEC_FILTERGIF
is enabled.

I received example patch from Mr. Joost Bekkers ( ),
but it doesn't fully work for kame IPSEC (kame ipsec seems to require having
pfil_hooks both before ipsec and after it, FAST_IPSEC queues the packet back
to ip_output so it works correctly with proposed fix).

More information about the freebsd-bugs mailing list