Re: kern/52313: NetBSD 8.0_BETA issues with ircd, ipfilter, and v6only=0 set

[Dominik Bialy <dmb%yenn.ulegend.net@localhost>]

On Tue, Jun 20, 2017 at 09:20:01AM +0000, Ryota Ozaki wrote:
> The following reply was made to PR kern/52313; it has been noted by GNATS.
> 
> From: Ryota Ozaki <ozaki-r%netbsd.org@localhost>
> To: "gnats-bugs%NetBSD.org@localhost" <gnats-bugs%netbsd.org@localhost>
> Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
> Subject: Re: kern/52313: NetBSD 8.0_BETA issues with ircd, ipfilter, and
>  v6only=0 set
> Date: Tue, 20 Jun 2017 18:14:57 +0900
> 
>  On Mon, Jun 19, 2017 at 4:15 AM,  <dmb%yenn.ulegend.net@localhost> wrote:
>  >>Number:         52313
>  >>Category:       kern
>  >>Synopsis:       NetBSD 8.0_BETA has issues with ircd (IRCnet one) + ipfilter + v6only=0 set
>  >>Confidential:   no
>  >>Severity:       serious
>  >>Priority:       medium
>  >>Responsible:    kern-bug-people
>  >>State:          open
>  >>Class:          sw-bug
>  >>Submitter-Id:   net
>  >>Arrival-Date:   Sun Jun 18 19:15:00 +0000 2017
>  >>Originator:     Dominik Bialy
>  >>Release:        NetBSD 8.0_BETA
>  >>Organization:
>  > Underlegend Networks
>  >>Environment:
>  > System: NetBSD yenn 8.0_BETA NetBSD 8.0_BETA (YENN) #2: Thu Jun 15 05:53:36 UTC 2017 builds@yenn:/var/obj/sys/arch/amd64/compile/YENN amd64
>  > Architecture: x86_64
>  > Machine: amd64
>  >>Description:
>  > When using an application which needs v6only=0 -- ircd (IRCnet one) --
>  > all connections on IPv4 are being reset.  There is ipfilter set.
>  > I was trying to pass all on it, but effect is the same.  I didn't try
>  > to disable ipfilter.  I'm not sure wether it's the ircd bug, or some
>  > bug/misfeature of NetBSD or ipfilter in it.
>  >
>  > I didn't test any other v6only=0 apps.
>  >
>  > PS: I can't restart the machine for now, so I can't test any fixes...
>  >>How-To-Repeat:
>  > Try to run IRCnet ircd with v6only=0 + ipfilter, and connecting using IPv4
>  
>  Is this a regression? Did the same setup work on NetBSD 7 or earlier?

Yes.  This setup worked well with NetBSD 6.

>  
>  What exactly happens on "all connections on IPv4 are being reset"?
>  - (I assume ircd is a server)

The server is ircd 2.11.2p3 -- latest IRCnet ircd you can get
from the maintainer's site: http://42.pl/ircd/

It relays on IPv6-mapped IPv4 addresses when configured with --ip6

It is compiled with -m32 since the code isn't 64-bit clean.

>  - Anyone cannot connect to the ircd? Or can connect but disconnect
>    for some reason?

The effect is "Connection reset by peer" when trying to connect to ircd (on IPv4)
either from outside or localhost (lo0). Connection doesn't even get established.
Connections initiated by ircd on IPv4 (server links) work well. IPv6 works well, too.

There are following rules on top of ipf.conf:

### block policy
block in all
block out all

### DEBUG
#pass in quick all
#pass out quick all

### antispoofing
block in from fc00::/7
block in on gif0 from fe80::/10
block in on gif0 from ::1/128
block in on ex0 from 10.0.0.0/8
block in on ex0 from 172.16.0.0/12
block in on ex0 from 192.168.0.0/16
block in on ex0 from 127.0.0.0/8
block in on ex1 from 127.0.0.0/8

### localhost
pass in quick on lo0 all
pass out quick on lo0 all

Later in the ipf.conf there is:

block return-rst in proto tcp from any to <external IP>

and then more specific rules that "pass" the traffic
on external IP.  We're passing all tcp traffic above port 1023,
and the ircd is on 6667.

And it smells like this is being trggered... but the "pass" rule
on lo0 above should just pass it.

I also used the "DEBUG" section for passing all,
and effect was the same.  I didn't try to disable ipfilter yet.

In fstat -nu irc:

irc      ircd        1581    7* internet6 stream tcp [::ffff:127.0.0.1]:6667

so it does listen, as well as on external IP.

>  - Where packets reach? ircd? ipfilter? the NIC?
>  
There are no symptoms of clients reaching the ircd (no traffic on
the &CLIENTS server channel).  I guess the NIC doesn't matter
since it happens on lo0, too.

I suspect ipfilter.  I had to do couple of changes to ipf.conf
since now there's one file for both IPv4 and IPv6, and the file
is pretty long.  Maybe one need to explicitly pass the ::ffff(...)
rules?  But how? Ipfilter parser returns errors with such notation,
and there is nothing about such addresses.

It might also be that something in the sockets API changed, and
this old ircd stopped working even though it was rebuilt for
NetBSD 8 (compat32).

PS:  I just did ipf -l block, and ipf -l nomatch, and nothing shows up
in ipmon...  But frankly speaking I'm green in ipf logging :P

>  Thanks,
>    ozaki-r
>  

What else checks I can do?

Thank you
	Dominik Biały