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 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