From nobody Sun Jun 04 17:08:31 2023 X-Original-To: freebsd-ipfw@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QZ39Y2gpqz4ZLJ5 for ; Sun, 4 Jun 2023 17:08:49 +0000 (UTC) (envelope-from freebsd@gushi.org) Received: from prime.gushi.org (prime.gushi.org [IPv6:2620:137:6000:10::142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "prime.gushi.org", Issuer "RapidSSL Global TLS RSA4096 SHA256 2022 CA1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QZ39X6Srlz3wsT for ; Sun, 4 Jun 2023 17:08:48 +0000 (UTC) (envelope-from freebsd@gushi.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (vpn-us.f.root-servers.org [149.20.8.9]) (authenticated bits=0) by prime.gushi.org (8.16.1/8.16.1) with ESMTPSA id 354H8gLK023952 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 4 Jun 2023 10:08:44 -0700 (PDT) (envelope-from freebsd@gushi.org) DKIM-Filter: OpenDKIM Filter v2.10.3 prime.gushi.org 354H8gLK023952 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gushi.org; s=prime2014; t=1685898525; bh=OmCMV3dsCGfLdOu64PfaXr7gfA4BaD1wkii45gki+7I=; h=Subject:From:In-Reply-To:Date:Cc:References:To; z=Subject:=20Re:=20Odd=20ipfw=20behavior=20with=20UDP=20query=20on= 20the=20same=20host|From:=20"Dan=20Mahoney=20(Ports)"=20|In-Reply-To:=20<202306041607.354G7ohW057620@gndrsh.dnsmg r.net>|Date:=20Sun,=204=20Jun=202023=2013:08:31=20-0400|Cc:=20"fre ebsd-ipfw@freebsd.org"=20|References:=20 <202306041607.354G7ohW057620@gndrsh.dnsmgr.net>|To:=20"Rodney=20W. =20Grimes"=20; b=qUVEAEIVFzryaUGK3SC+snL1yQQFkY5mdJv7BUYj0VbSJGwE79JA/WB609aHME39r cuvEvivVgiHoSq5ff/YFdWyRj9RRrWTs1XbIeodpy1wKD7LP1asgiWUwpGAs4fvuOb UhFIba7FWqkgejGe+pbd9fWyLUFXbjAZX747XdHYJUUNjbYehF7RVZk9IKj7ObwZAo RsMRrTtMoNJCoxzSPuIkRvnQ8jomoaDbViPmc8Se8+s8vk040W9IyAVrqO+IENpL1L LLRB/zzPnI+JUOm3bosk+SQIw0K2Etu8uWgFS5e0eKXPfXN55FZ0PLIhgUEGfWRtG3 ZkmQ64OGfxYcg== X-Authentication-Warning: prime.gushi.org: Host vpn-us.f.root-servers.org [149.20.8.9] claimed to be smtpclient.apple Content-Type: text/plain; charset=utf-8 List-Id: IPFW Technical Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-ipfw List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ipfw@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: Odd ipfw behavior with UDP query on the same host From: "Dan Mahoney (Ports)" In-Reply-To: <202306041607.354G7ohW057620@gndrsh.dnsmgr.net> Date: Sun, 4 Jun 2023 13:08:31 -0400 Cc: "freebsd-ipfw@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <202306041607.354G7ohW057620@gndrsh.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3731.600.7) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (prime.gushi.org [149.20.68.142]); Sun, 04 Jun 2023 17:08:45 +0000 (UTC) X-Rspamd-Queue-Id: 4QZ39X6Srlz3wsT X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:393507, ipnet:2620:137:6000::/44, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On Jun 4, 2023, at 12:07 PM, Rodney W. Grimes = wrote: >=20 >> Hey ipfw folks ? Im skipping questions@ and asking this directly = here, >>=20 >> FreeBSD 12.4 (amd64) >>=20 >> Assume a partial firewall ruleset like this: >>=20 >> 00300 0 0 allow ip from any to any via lo0 >> 00400 0 0 allow ip from any to any via lo1 >> 00500 0 0 deny ip from any to 127.0.0.0/8 in >> 00600 0 0 deny ip from any to ::/64 in >> 01600 1 174 allow ip from any to me 53 in // DNS queries >=20 > 1650 x x allow ip from me 53 to me in // DNS local answers >=20 >> 01700 1 293 allow ip from me 53 to any out // DNS responses >> 03000 0 0 reset log ip from any to any >> 65535 0 0 allow ip from any to any >>=20 >> For some reason, with the above, I?m able to query a DNS server = living on my own (public) ipv6 interface, i,e: >>=20 >> dig @2001:b00b:6b:2::53 version.bind CH TXT: >> ;communications error to 2001:b00b:6b:2::53#53: timed out >>=20 >> This is not a bind config problem. Bind answers from outside and = everywhere else but itself. >=20 > We can argue about that, but given the below log entries your not = using ::1 > for local ipv6 dns, but your using your interface ipv6 address. > What is in your /etc/resolv.conf file? That doesn=E2=80=99t matter, this isn=E2=80=99t the box=E2=80=99s local = resolver, it=E2=80=99s an authoritative server that we=E2=80=99re = sending test queries against to make sure it=E2=80=99s answering. They = work from off-box but not on-box. I=E2=80=99m posting from my personal account, but you could say my day = job is very familiar with dig and bind. :) >> =3D=3D >>=20 >> If I change rule 1600 to simply be "allow ip from any to me 53? it = works. =20 >>=20 >> If I do ipfw disable firewall it works. =20 >>=20 >> Localhost always works. > As long as ipv4 is done first, if you flip the order of preference for > ipv4 and ipv6 it probably stops working. It does not. See below, I test all iterations of tcp/udp ipv4/ipv6 box = ip/localhost =E2=80=94 the only failing one is interface-ip, ipv6, udp >=20 >>=20 >> Using the ipv4 address works. >>=20 >> =3D=3D >>=20 >> It?s only when using an ipv6 interface ip on the same box that this = breaks. TCP also works, this only seems to be a UDP issue. >=20 > How are you testing the TCP? Same as we=E2=80=99re testing the UDP. With dig. dig +short @boxname version.bind CH TXT ;; communications error to 2001:b00b:1:f::88#53: timed out ;; communications error to 2001:b00b:1:f::88#53: timed out ;; communications error to 2001:b00b:1:f::88#53: timed out "9.16.40" $ dig +short @localhost version.bind CH TXT "9.16.40" $ dig +short +tcp @localhost version.bind CH TXT "9.16.40" $ dig +short +tcp @boxname version.bind CH TXT "9.16.40" $ dig -4 +short +tcp @boxname version.bind CH TXT "9.16.40" $ dig -4 +short @boxname version.bind CH TXT "9.16.40" $ dig -4 +short @localhost version.bind CH TXT "9.16.40" $ dig -4 +short +tcp @localhost version.bind CH TXT "9.16.40" >=20 >> My best guess is something about the ?inbound/outbound? determination = logic is weird in ipv6. >>=20 >> My log rule shows:=20 >> Jun 3 23:44:35 box kernel: ipfw: 3000 Deny UDP = [2001:b00b:6b:2::53]:53 [2001:b00b:6b:2::53]:26588 in via em0 >> Jun 3 23:44:40 box kernel: ipfw: 3000 Deny UDP = [2001:b00b:6b:2::53]:53 [2001:b00b:6b:2::53]:32389 in via em0 >=20 > The clue as to what is wrong is right here = ----------------------------------------------------------^^^^^^^^^^ >=20 > The src and dst IP address of those packets is the same, and I am = going to assume that it is the > interface address of em0. Nothing in your rule allows these packets = through, which are local > answers from DNS to local queries made to that interface IP address. Given the routing table below (which is for a different box with a = similar route), why was this not sent via lo0? >=20 >>=20 >> ipv4 doesn?t show this problem. Subnet masks and the like are = correct. >=20 > ipv4 has a special loopback route on lo0 that does not exist for ipv6. > Look at: > netstat -rn Here you go, annotations mine. I=E2=80=99m not seeing it. Internet: Destination Gateway Flags Netif Expire default 149.99.1.1 UGS igb0 (A) 127.0.0.1 link#3 UH lo0 (B) 149.99.1.0/25 link#1 U igb0 (C) 149.99.1.88 link#1 UHS lo0 (D) Internet6: Destination Gateway Flags = Netif Expire ::/96 ::1 UGRS = lo0 (no v4 equivalent) default 2001:b00b:1:f::1 UGS = igb0 (A) ::1 link#3 UH = lo0 (B) ::ffff:0.0.0.0/96 ::1 UGRS = lo0 (No v4 equivalent) 2001:b00b:1:f::/64 link#1 U = igb0 (C) 2001:b00b:1:f::88 link#1 UHS = lo0 (D) (plus a bunch of fe80 stuff) fe80::/10 ::1 UGRS = lo0 fe80::%igb0/64 link#1 U = igb0 fe80::ae1f:6bff:fe83:2380%igb0 link#1 UHS = lo0 fe80::%lo0/64 link#3 U = lo0 fe80::1%lo0 link#3 UHS = lo0 ff02::/16 ::1 UGRS = lo0 A: default route (statically configured, main interface) B: Loopback (yes, v6 land has an additional loopback subne, lo0t) C: route for the interface block (which shows as the interface name) D: route for my own ip (which shows as lo0) Now, if BIND is doing something wrong with the interface selection = logic, I=E2=80=99d love to know about that too, but it should just be = honoring the kernel routing table. The keyword =E2=80=9Cin=E2=80=9D seems to be problematic, and the = manpage doesn=E2=80=99t cover what constitutes an =E2=80=9Cinbound=E2=80=9D= or =E2=80=9Coutbound=E2=80=9D rule in this case (where it=E2=80=99s the = same box). Trying to search the manpage for =E2=80=9Cin=E2=80=9D is not = helpful, but this is all I see. In cases like this, do these rules go through ipfw twice? in | out Matches incoming or outgoing packets, respectively. in and = out are mutually exclusive (in fact, out is implemented as not = in). -Dan