Subject: kern/29560: latest ipfilter does not allow certain IPSEC related traffic through
To: None <,,>
From: None <>
List: netbsd-bugs
Date: 02/28/2005 20:04:00
>Number:         29560
>Category:       kern
>Synopsis:       latest ipfilter does not allow certain IPSEC related traffic through
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 28 20:04:00 +0000 2005
>Originator:     Arto Selonen
>Release:        NetBSD-current 2.99.16 ~20050228
NetBSD blah 2.99.16 NetBSD 2.99.16 (BLAH) #80: Mon Feb 28 16:53:49 EET 2005  blah@blah:/obj/sys/arch/i386/compile/BLAH i386

See kern/25087 and kern/26529. This seems to be quite close to those
two, except that turning related NAT rules off does not seem to have
much effect, so I don't have a workaround. Those two PRs were closed
just prior to 4.1.5, and now 4.1.6 traffic does not flow.
ANNOYING AS HELL! IPSEC connection is semi-useless, but then again
it only worked for one month (February 2005) since late March 2004
(after having worked for a couple of years).

Am I supposed to go through all closed PRs every time ipfilter
is upgraded in NetBSD?

As you can guess, I'm very, very annoyed. I'll provide more coherent
details when I calm down... All I know is that I can see the client
traffic go through the box, and see responses coming back to it.
ipmon does not report blocking anything special, yet I'm not getting
the reponses at the other end of the IPSEC pipe. As bin/25796
prevents further analysis on IPSEC-side, I can only assume that
this is related to OOW detection, as it was my assumption, that
the original problems were solved by Christos Zoulas disabling OOW
code in ipfilter 4.1.3. I guess all the crap is back?
Wait for ipfilter upgrade in NetBSD-current, "works" every time!
One could also wait for an upcoming NetBSD .0 release, as they
seem to have the same effect. I'm not sure if these two are related!
PF, but presumably it is not ready for prime time in NetBSD, so
maybe OpenBSD/FreeBSD.