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

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

The following reply was made to PR kern/52313; it has been noted by GNATS.

From: Dominik Bialy <dmb%yenn.ulegend.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost, dmb%yenn.ulegend.net@localhost
Subject: Re: kern/52313: NetBSD 8.0_BETA issues with ircd, ipfilter, and
 v6only=0 set
Date: Tue, 20 Jun 2017 13:54:11 +0200

 On Tue, Jun 20, 2017 at 01:19:57PM +0200, Dominik Bialy wrote:
 > 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
 
 More info -- I just run irc nick 127.0.0.1 (ircII client), and it showed
 
 error in getsockname()
 
 I can't reproduce it since another try gave "Connection reset by peer"
 
 Also it seems that ircd-hybrid, which I was giving a try, can't bind
 to AF_INET et all... (it has listen{} on all ports 6661-6669.) No
 internet sockets are showing up in fstat.
 
 Also irssi is giving that warning:
 
 ** (irssi:5441): WARNING **: settings_get_time(server_connect_timeout) : Invalid time '-1'
 
 Hope we are closer... :)
 	Dominik