From owner-freebsd-pf@freebsd.org Sun Jan 8 15:05:33 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E607CA5EE6 for ; Sun, 8 Jan 2017 15:05:33 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [88.199.43.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "plan-b.pwste.edu.pl" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 155801199 for ; Sun, 8 Jan 2017 15:05:32 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPS id v08EtXf1047767 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 8 Jan 2017 15:55:33 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.15.2/8.15.2/Submit) id v08EtWHp047763 for freebsd-pf@freebsd.org; Sun, 8 Jan 2017 15:55:32 +0100 (CET) (envelope-from zarychtam) Date: Sun, 8 Jan 2017 15:55:32 +0100 From: Marek Zarychta To: freebsd-pf@freebsd.org Subject: udp - weird behavior of reply-to Message-ID: <20170108145532.GA17695@plan-b.pwste.edu.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 15:05:33 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable For a long period of time, I have been using reply-to rules for a few TCP and one UDP service which had been introduced for HA reasons and are used quite rarely.=20 After upgrade to 11-STABLE the rules for TCP traffic work as expected, providing kind of symmetric routing, but UDP traffic ignores reply-to directive and UDP service is responding only partially via default gateway. Worse, only one UDP segment passes in one direction for UDP service. As a result, the whole communication is broken. PF states look like this: all udp 88.199.x.x:1197 <- 62.x.y.z:58781 NO_TRAFFIC:SINGLE all udp 88.199.y.y:1197 -> 62.x.y.z:58781 SINGLE:NO_TRAFFIC Similar rule for tcp traffic works flawlessly:=20 all tcp 88.199.x.x:50001 <- 62.x.y.z:56330 ESTABLISHED:ESTABLISHED It is not an underlying service issue, additional tests were performed using netcat. The rules weren't changed, at least since the machine was running 9-STABLE and then everything worked correctly. The machine is currently running 11.0-STABLE r311637 compiled for i386 arch. Is it a bug to be officially submitted or it will not be possible to use reply-to for UDP traffic anymore? --=20 Marek Zarychta --DocE+STaALJfprDB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlhyUuEACgkQdZ/s//1S jSyz4AgAoICDnUaabnhlQTIs67CMXZD3XnZwmbdggVcr2VIC+kePF8Edyz9cr9bK 60zHxGuhFazWY5S2CqvtLEE2AEdwKmpo/IkSy+NG2MrCXKJj+mDMFYpB3/a3+f9S +BEL+S2cxZOedDS+MpIBGCUiS3dAdTTrplXDrSDuF32ykU4gmEFBx6tiAmWvPnD9 qMlkwKp5mWTPMpuiRIkyXJPmY01VWXWQahCY5M85mvxjmv7wkCmjg+7uwufV3MXm CIabbKy+F45kTWBMcZyDj9rbpQi7UQd9ThA0qsoS5BEUxmHKoJ5wigotdLHB9Qrs q4hfUPmz7C3H+Slfi2U0ZePXsvNr4w== =kb3f -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From owner-freebsd-pf@freebsd.org Sun Jan 8 18:08:13 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2EA3CA5AF9 for ; Sun, 8 Jan 2017 18:08:13 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 804F51AE9 for ; Sun, 8 Jan 2017 18:08:13 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [10.0.2.164] (ptr-8ripyyi2hbevfdej7yn.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:f161:e32d:7614:810f]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 73B2F1F6CD; Sun, 8 Jan 2017 19:08:11 +0100 (CET) From: "Kristof Provost" To: "Marek Zarychta" Cc: freebsd-pf@freebsd.org Subject: Re: udp - weird behavior of reply-to Date: Sun, 08 Jan 2017 19:08:10 +0100 Message-ID: In-Reply-To: <20170108145532.GA17695@plan-b.pwste.edu.pl> References: <20170108145532.GA17695@plan-b.pwste.edu.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6072) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 18:08:13 -0000 On 8 Jan 2017, at 15:55, Marek Zarychta wrote: > Is it a bug to be officially submitted or it will not be possible to > use > reply-to for UDP traffic anymore? > The problem description doesn’t ring any bells with me, but I’m also not sure I’ve fully understood it. Can you document a minimal reproduction scenario, with a pf.conf and perhaps network captures documenting the problem? There’s certainly not been a conscious decision to break UDP reply-to. Regards, Kristof From owner-freebsd-pf@freebsd.org Sun Jan 8 20:47:25 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EC63CA5D24 for ; Sun, 8 Jan 2017 20:47:25 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [88.199.43.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "plan-b.pwste.edu.pl" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D8C31BCB; Sun, 8 Jan 2017 20:47:24 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPS id v08KlJU9079026 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 8 Jan 2017 21:47:19 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.15.2/8.15.2/Submit) id v08KlJ04079025; Sun, 8 Jan 2017 21:47:19 +0100 (CET) (envelope-from zarychtam) Date: Sun, 8 Jan 2017 21:47:19 +0100 From: Marek Zarychta To: Kristof Provost Cc: freebsd-pf@freebsd.org Subject: Re: udp - weird behavior of reply-to Message-ID: <20170108204719.GA8598@plan-b.pwste.edu.pl> References: <20170108145532.GA17695@plan-b.pwste.edu.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LpQ9ahxlCli8rRTG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 20:47:25 -0000 --LpQ9ahxlCli8rRTG Content-Type: multipart/mixed; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 08, 2017 at 07:08:10PM +0100, Kristof Provost wrote: > On 8 Jan 2017, at 15:55, Marek Zarychta wrote: > The problem description doesn=E2=80=99t ring any bells with me, but I=E2= =80=99m also=20 > not sure > I=E2=80=99ve fully understood it. Can you document a minimal reproductio= n=20 > scenario, > with a pf.conf and perhaps network captures documenting the problem? >=20 Network captures taken with tcpdump are quite simple: 1st msg from client 20:20:38.726593 IP 62.133.x.y.38315 > 88.199.x.y.1197: UDP, length 21 2nd msg from client 20:20:45.105679 IP 62.133.x.y.38315 > 88.199.x.y.1197: UDP, length 21 20:20:45.106680 IP 88.199.x.y > 62.133.x.y: ICMP 88.199.x.y udp port 1197 unreachable, length 36 1st reply from service:=20 20:21:11.191630 IP 88.199.y.z.1197 > 62.133.x.y.38315: UDP, length 24 2nd reply from service:=20 20:21:44.838787 IP 88.199.y.z.1197 > 62.133.x.y.38315: UDP, length 37 Only one UDP datagram passes the firewall from client to server, the rest is bounced. All the replies are sent via wrong interface. When I start service with another fib, where the interface has default gateway in scope, communication goes fine. It could be still possible to run two instances of service, but this is not what reply-to was intended for. By the way, negotiation of TCP connection via second interface goes sucessful: 20:23:52.143832 IP 62.133.x.y.42426 > 88.199.105.83.22: Flags [S], seq 3881242448, win 29200, options [mss 1412,sackOK,TS val 57770500 ecr 0,nop,wscale 7], length 0 20:23:52.143927 IP 88.199.x.y.22 > 62.133.x.y.42426: Flags [S.], seq 430799235, ack 3881242449, win 65535, options [mss 1412,nop,wscale 9,sackOK,TS val 615314394 ecr 57770500], length 0 20:23:52.163432 IP 62.133.x.y.42426 > 88.199.x.y.22: Flags [.], ack 1, win 229, options [nop,nop,TS val 57770505 ecr 615314394], length 0 The minimal pf.conf for use in reproduction scenario is attached.=20 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="pf.conf.simple" Content-Transfer-Encoding: quoted-printable ext_if =3D "em0" # em0 is parent interface of vlan2 ext_if_2 =3D "vlan2" ip_gw_1 =3D "88.199.p.q" # ip_gw_1 is default gateway=20 ip_gw_2 =3D "88.199.r.s" # ip_gw_2 is default gw for fib 1 # uslugi tcp_services =3D "{ 22, 50000:55000 }" udp_services =3D "{ 1194:1199 }" TCP_OPTIONS =3D "flags S/SA keep state" UDP_OPTIONS =3D "keep state" set block-policy return set loginterface $ext_if set skip on { lo, tun } scrub in on {$ext_if, $ext_if_2} all # ---- # ICMP # ---- pass out quick on { $ext_if, $ext_if_2 } inet proto icmp all \ icmp-type 8 code 0 keep state=20 pass in quick on $ext_if inet proto icmp all \ icmp-type 8 code 0 keep state=20 pass in quick on $ext_if_2 reply-to ( $ext_if_2 $ip_gw_2 ) \ inet proto icmp all \ icmp-type 8 code 0 keep state # --- # UDP # --- pass in quick on $ext_if inet proto udp \ from any \ to ($ext_if:0) port $udp_services \ $UDP_OPTIONS=20 =20 pass in quick on $ext_if_2 \ reply-to ( $ext_if_2 $ip_gw_2 ) \ inet proto udp \ from any \ to ($ext_if_2:0) port $udp_services \ $UDP_OPTIONS=20 pass out quick on {$ext_if, $ext_if_2} proto udp \ all \ $UDP_OPTIONS=20 # --- # TCP # --- pass in quick on $ext_if inet proto tcp \ from any \ to ($ext_if:0) port $tcp_services \ $TCP_OPTIONS =20 pass in quick on $ext_if_2 \ reply-to ( $ext_if_2 $ip_gw_2 ) \ inet proto tcp \ from any \ to ($ext_if_2:0) port $tcp_services \ $TCP_OPTIONS =20 pass out quick on {$ext_if, $ext_if_2} proto tcp \ all \ $TCP_OPTIONS=20 --2oS5YaxWCcQjTEyO-- --LpQ9ahxlCli8rRTG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlhypVQACgkQdZ/s//1S jSyzCggAm4qRbboi3nZ3duWpDCtNRgfFDGiCpleotj+g2wZ82uLyldx9l+jgGjCx d43M8Plrv/LKFq/bCfpojnWZVdHFwZ7MlSNs6XpU9RLcjRP+TSlWfeZJi9OGfyLO MRcaxQKzMCtg33NF9X2t80xktzQgrZbys+KIpwqd/iIRNcyz1KYhf2VPoyhEqOhV tFcD57jMl0GEwr/+dTyWFXktWTtWh5VTQVT1w8BRmxJvCBm9DrZw3L4a+04tHvJr lgzntxyl+sH018esYqos8Nx9HhF/eFbhSejX3QCYe5Mww6PwhxtWjKEjtKIZLkwj 50RGcPyHatAee50L1WLE0qRNCyxlNg== =QIak -----END PGP SIGNATURE----- --LpQ9ahxlCli8rRTG-- From owner-freebsd-pf@freebsd.org Sun Jan 8 21:00:37 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB56ECA6697 for ; Sun, 8 Jan 2017 21:00:37 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C6BE518FC for ; Sun, 8 Jan 2017 21:00:37 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v08L01pY092914 for ; Sun, 8 Jan 2017 21:00:37 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201701082100.v08L01pY092914@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-pf@FreeBSD.org Subject: Problem reports for freebsd-pf@FreeBSD.org that need special attention Date: Sun, 08 Jan 2017 21:00:37 +0000 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 21:00:38 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 203735 | Transparent interception of ipv6 with squid and p 1 problems total for which you should take action. From owner-freebsd-pf@freebsd.org Mon Jan 9 00:23:08 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8D34CA3409 for ; Mon, 9 Jan 2017 00:23:08 +0000 (UTC) (envelope-from admin@x249.save85off.com) Received: from x249.save85off.com (x249.save85off.com [43.240.238.249]) by mx1.freebsd.org (Postfix) with ESMTP id 7951D19FB for ; Mon, 9 Jan 2017 00:23:08 +0000 (UTC) (envelope-from admin@x249.save85off.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=save85off; d=x249.save85off.com; h=MIME-Version:From:To:Date:Subject:Content-Type:Content-Transfer-Encoding; i=admin@x249.save85off.com; bh=UxqTc7t3Veu1Rm2w7+1k5JgxHIc=; b=EWcDMYxe3jkc7qW29ofltv+ntl+e3rv9ZRyHug5KzkKbgvKsm8VJ8RiUFdGjIuCv0bM6myt3zdlX 81Jp0ljIUTOQvM45A5ptBN+dMzbyRaBc9aJpl+tQgeX+eu7ZrH9AqPFXw1k08xrCVG0dhgtuj1eU LFSYw6iB9NWgyundoBU= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=save85off; d=x249.save85off.com; b=jLMioJOue/LwPlFEkMUbLl+ZCy57rXpwdL3DPJtNc835d/oKEGSNOgNAT+81beXXZzKlunfgob8i UPvfA9wi3ALHakP+3piAt9T89YdpdKPpchxLoBFC2u6M21tgkR2Mpv14xfz+kCx3ixo0PrE487qq 0iswQSM62w6jbhNMDnY=; From: "UGG Australia Boots" To: freebsd-pf@freebsd.org Date: 9 Jan 2017 08:12:48 +0800 Subject: New Year Door busters are here NOW win 73$ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 00:23:08 -0000 From owner-freebsd-pf@freebsd.org Mon Jan 9 17:25:30 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FC90CA7B32 for ; Mon, 9 Jan 2017 17:25:30 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [88.199.43.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "plan-b.pwste.edu.pl" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F077F1BAC; Mon, 9 Jan 2017 17:25:29 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPS id v09HPKub094437 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Jan 2017 18:25:20 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.15.2/8.15.2/Submit) id v09HPJPX094431; Mon, 9 Jan 2017 18:25:19 +0100 (CET) (envelope-from zarychtam) Date: Mon, 9 Jan 2017 18:25:19 +0100 From: Marek Zarychta To: Kristof Provost Cc: freebsd-pf@freebsd.org Subject: Re: udp - weird behavior of reply-to Message-ID: <20170109172519.GA62580@plan-b.pwste.edu.pl> References: <20170108145532.GA17695@plan-b.pwste.edu.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 17:25:30 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 08, 2017 at 07:08:10PM +0100, Kristof Provost wrote: > On 8 Jan 2017, at 15:55, Marek Zarychta wrote: > The problem description doesn=E2=80=99t ring any bells with me, but I=E2= =80=99m also=20 > not sure > I=E2=80=99ve fully understood it. Can you document a minimal reproductio= n=20 > scenario, > with a pf.conf and perhaps network captures documenting the problem? >=20 > There=E2=80=99s certainly not been a conscious decision to break UDP repl= y-to. >=20 Let me apologize, the problem wasn't previously properly identified. It seems to be more problem of UDP protocol implementation than PF issue. UDP sockets are opened and bound to address of the outgoing interface (interface which has a route to the client). Because the socket is not bound to the incoming interface, the PF reply-to rules couldn't be evaluated. By the way, TCP sockets are bound to the interface where the traffic arrives and everything works fine.=20 This machine is i386 running 11.0-STABLE r311772 The problem remains unresolved. Are there any corresponding sysctls correcting this behavior and enabling the opportunity to use PF assisted symmetric routing scenario again?=20 --=20 Marek Zarychta --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlhzx30ACgkQdZ/s//1S jSwKZAgAy+LxWRJgn9fMuZCvDC0qHDixrKsOteETi1LQ9p0/dZjsmaGAIk223sVa Z3ui83hR4DgNPn2OtrM72ItYjVv5s+7JAl3PhlcsZNkBa7eHpxjDZ+VvVE/s/Noz djG+oNIVe6DHycB9XSKoIqVs16NNnvXljjHixpQUPe/oJFqbqDuryEJb70egAokT HLvmr64zInpo1Pn3yangUTmz0C1m/VliThhG7xuFRMd4rpBkqeBMFQIIpIR+vxf1 g/E+9J2FwahNFeJLXJab9mkra9Ottfjdker4NZq0ppHQ+oxgpQCw/GGQXIqF+Tam /af5HyagqtUCSLjobvRL5a6JFPd8TQ== =e3e4 -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- From owner-freebsd-pf@freebsd.org Mon Jan 9 20:58:43 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8ED59CA799E for ; Mon, 9 Jan 2017 20:58:43 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8F012B0 for ; Mon, 9 Jan 2017 20:58:43 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [192.168.228.1] (vega.codepro.be [IPv6:2a01:4f8:162:1127::3]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 06C9B1FE4D; Mon, 9 Jan 2017 21:58:40 +0100 (CET) From: "Kristof Provost" To: "Marek Zarychta" Cc: freebsd-pf@freebsd.org Subject: Re: udp - weird behavior of reply-to Date: Mon, 09 Jan 2017 21:58:38 +0100 Message-ID: In-Reply-To: <20170109172519.GA62580@plan-b.pwste.edu.pl> References: <20170108145532.GA17695@plan-b.pwste.edu.pl> <20170109172519.GA62580@plan-b.pwste.edu.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6072) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:58:43 -0000 On 9 Jan 2017, at 18:25, Marek Zarychta wrote: > On Sun, Jan 08, 2017 at 07:08:10PM +0100, Kristof Provost wrote: >> On 8 Jan 2017, at 15:55, Marek Zarychta wrote: >> The problem description doesn’t ring any bells with me, but I’m >> also >> not sure >> I’ve fully understood it. Can you document a minimal reproduction >> scenario, >> with a pf.conf and perhaps network captures documenting the problem? >> >> There’s certainly not been a conscious decision to break UDP >> reply-to. >> > > Let me apologize, the problem wasn't previously properly identified. > It > seems to be more problem of UDP protocol implementation than PF issue. > UDP sockets are opened and bound to address of the outgoing interface > (interface which has a route to the client). Because the socket is not > bound to the incoming interface, the PF reply-to rules couldn't be > evaluated. By the way, TCP sockets are bound to the interface where > the > traffic arrives and everything works fine. > This machine is i386 running 11.0-STABLE r311772 > > The problem remains unresolved. Are there any corresponding sysctls > correcting this behavior and enabling the opportunity to use PF > assisted > symmetric routing scenario again? > How are your UDP listen sockets set up? Are they bound to a specific interface, or are they listening on 0.0.0.0? I’m afraid I’m still struggling to understand what your setup is, what you’re expecting to see and what you’re seeing instead. Regards, Kristof From owner-freebsd-pf@freebsd.org Mon Jan 9 21:32:35 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A7DCCA8710 for ; Mon, 9 Jan 2017 21:32:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A31A18DF for ; Mon, 9 Jan 2017 21:32:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v09LWZt1068650 for ; Mon, 9 Jan 2017 21:32:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 215716] [altq] pfctl: DIOCADDALTQ: Cannot allocate memory Date: Mon, 09 Jan 2017 21:32:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-pf@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 21:32:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215716 --- Comment #3 from Kristof Provost --- Created attachment 178681 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D178681&action= =3Dedit Remove bogus checks I'm very confused by these checks. The RMCF_* flags they check for are never actually set anywhere. This patch should at least unblock you. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Mon Jan 9 21:33:09 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9ECDBCA8749 for ; Mon, 9 Jan 2017 21:33:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8EA131960 for ; Mon, 9 Jan 2017 21:33:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v09LX9jS069437 for ; Mon, 9 Jan 2017 21:33:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 215716] [altq] pfctl: DIOCADDALTQ: Cannot allocate memory Date: Mon, 09 Jan 2017 21:33:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: kp@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: loos@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 21:33:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215716 Kristof Provost changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-pf@FreeBSD.org |loos@FreeBSD.org --- Comment #4 from Kristof Provost --- This needs to be looked at closer, because something is very wrong with the= se checks. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-pf@freebsd.org Mon Jan 9 22:17:17 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83C69CA775B for ; Mon, 9 Jan 2017 22:17:17 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [88.199.43.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "plan-b.pwste.edu.pl" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 28BEE1488; Mon, 9 Jan 2017 22:17:16 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPS id v09MHCdk087575 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 9 Jan 2017 23:17:12 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.15.2/8.15.2/Submit) id v09MHCpA087572; Mon, 9 Jan 2017 23:17:12 +0100 (CET) (envelope-from zarychtam) Date: Mon, 9 Jan 2017 23:17:12 +0100 From: Marek Zarychta To: Kristof Provost Cc: freebsd-pf@freebsd.org Subject: Re: udp - weird behavior of reply-to Message-ID: <20170109221712.GA49594@plan-b.pwste.edu.pl> References: <20170108145532.GA17695@plan-b.pwste.edu.pl> <20170109172519.GA62580@plan-b.pwste.edu.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:17:17 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 09, 2017 at 09:58:38PM +0100, Kristof Provost wrote: > On 9 Jan 2017, at 18:25, Marek Zarychta wrote: > > On Sun, Jan 08, 2017 at 07:08:10PM +0100, Kristof Provost wrote: > >> On 8 Jan 2017, at 15:55, Marek Zarychta wrote: > >> The problem description doesn=E2=80=99t ring any bells with me, but I= =E2=80=99m=20 > >> also > >> not sure > >> I=E2=80=99ve fully understood it. Can you document a mi= nimal reproduction > >> scenario, > >> with a pf.conf and perhaps network captures documenting the problem? > >> > >> There=E2=80=99s certainly not been a conscious decision to break UDP= =20 > >> reply-to. > >> > > > > Let me apologize, the problem wasn't previously properly identified. = =20 > > It > > seems to be more problem of UDP protocol implementation than PF issue. > > UDP sockets are opened and bound to address of the outgoing interface > > (interface which has a route to the client). Because the socket is not > > bound to the incoming interface, the PF reply-to rules couldn't be > > evaluated. By the way, TCP sockets are bound to the interface where=20 > > the > > traffic arrives and everything works fine. > > This machine is i386 running 11.0-STABLE r311772 > > > > The problem remains unresolved. Are there any corresponding sysctls > > correcting this behavior and enabling the opportunity to use PF=20 > > assisted > > symmetric routing scenario again? > > > How are your UDP listen sockets set up? > Are they bound to a specific interface, or are they listening on=20 > 0.0.0.0? Yes, socket is listening on 0.0.0.0, the client from outside network is initiating connection and initiating packet arrives on interface B, which is supposed only to communicate with devices on its own network (no additional routes go via this interface), so normally the reply would be passed via interface A having default gateway in scope and communication would fail. =20 With the assistance of PF reply-to rule, TCP services are able to pass reply from interface B via other, second gateway: reply-to (B GW2).=20 This functionality is currently broken for any UDP service, because UDP sockets are always opened on supposed_to_be_outgoing interface A and bound to the address of this interface, which is considered good from routing table perspective, but silently breaks PF reply-to for UDP. When the machine was running 9-STABLE reply-to had successfully been used to assist both TCP and UDP driven services.=20 Is anyone reading this list still using reply-to rule for routing UDP traffic back via incoming interface? Maybe currently, the better place to discuss this questions would be freebsd-net, but the thread was initiated here. >=20 > I=E2=80=99m afraid I=E2=80=99m still struggling to understand what your s= etup is,=20 > what you=E2=80=99re > expecting to see and what you=E2=80=99re seeing instead. >=20 > Regards, > Kristof --=20 Marek Zarychta --azLHFNyN32YCQGCU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlh0C+QACgkQdZ/s//1S jSwDDwf/Z5WP6emeAaU2OVU/5hLZzG0t9WoNuGzmk3krqIqiA9MQtQjyq4zPQbXq xk3LS3fpim3IX4vQzww/L5QhaQD+3x1J0YHc+8kYy1+1oLeGDagFCy4WHPav5FRt l6cOn9EvL9nSqSiMvZu2QXjnMyGbx92g79LYU4pysr15Dv4SUFAVqgP0qwdojb8V ++hLaWDM41JPV65ECFJNiOMM/5TfZpff/F5p0bOSU+BHw8Zby13rH+jGqRhFA8XR ppwJrBjUg4E9vpkI2ZMVuSkAXgO1Yg9VD1X3cfUizKs8Gtj1n0MhT3dXro/5OTcJ TN8nyZSmRHQZFw0jaaiD3mYqUlfS3g== =lBju -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-pf@freebsd.org Tue Jan 10 03:01:24 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73FB2CA845B for ; Tue, 10 Jan 2017 03:01:24 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 361501A38 for ; Tue, 10 Jan 2017 03:01:23 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by mail-yw0-x230.google.com with SMTP id w75so44693296ywg.1 for ; Mon, 09 Jan 2017 19:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=capeaugusta-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=oghQnEitylGCxv0vXNwDelLoUTSyIlwQy91EW/TxlKM=; b=RSpw265f41MPWK/oJGYk5WgtFn171HPV9Dwrcy3nBlqPIXM/knJgEwljnBXpoR3ikw ntT/GNG7W9HwW9WQnYRBMQmRqluLlP+cv5TitKiGAZ6VIf3f+qCQu0b098HlWbVXKBkb uZwwOSFuKwjaXZ4bMuYFyhACJBUcNP6cwZpr/etjLYAV57xgPdBBRO2bc5V5tVSQXVIV CsQU4u4Tq1P92s456GqAcdF+dMQ6a/kFs8MAiVofQjs3ERvnGLoCVnGheZL0UdM/AYIZ Jt8x8X27AWpgyLlhH7eW2MCu6cla8Qv+w15VDGJs/bgeNsPjnQnq2tj26olUqZNssmk2 7CGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=oghQnEitylGCxv0vXNwDelLoUTSyIlwQy91EW/TxlKM=; b=epIXn2SQ2RwWRf8PArWuAm2oWoN1Tzzgc/ErXcRjyKqlKGZaN8xiUf2vHRBcS47sRX fqLfsBqT2Zdm2voKXMSJ2A0LzqRMK/3qk+3ipvrDOWE9YD6pqW1bVdhZRlUJtllTMpWB mIZoD1q9rZjXY5WEA7uZN9MYYRd6A0eFOueQ3CdUYpz2y8rE6DqEf2gMutDB5PHKYGCR aKwv6czfwew9Wy1+1xaDkv7UaGoBrKDjYMIAIvMcQURcwGqynS4OQefTeQWhG4BgSrAY yPejipJyqi6q2yqLX/oNASZcn/8Dgi8xBADMfSRSBNdz4fo4cHMQfuM/5EmExmJaqkIY z5xw== X-Gm-Message-State: AIkVDXLQYtpYpQvMSXHhc2ItiFx3zPM1e7aVAT7bxuMOnFlWmg9Pawi93qNtiwZVmygwwkxZD5cwxfwItue1cjaE4887aJgSAPAQWVYZGskstlbOw0Kr13mJHHKOtRoWIzgEhJ9Wxgl191rTtoau0s25tQT5izuzvO3/aZI5bvlA5AqNEgBsN/v8TXrLbTulEg6KzA== X-Received: by 10.129.137.194 with SMTP id z185mr934687ywf.159.1484017282413; Mon, 09 Jan 2017 19:01:22 -0800 (PST) Received: from zen.clue.co.za (c-73-217-184-74.hsd1.ga.comcast.net. [73.217.184.74]) by smtp.gmail.com with ESMTPSA id p1sm266544ywh.52.2017.01.09.19.01.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jan 2017 19:01:21 -0800 (PST) Subject: Re: udp - weird behavior of reply-to To: freebsd-pf@freebsd.org References: <20170108145532.GA17695@plan-b.pwste.edu.pl> <20170109172519.GA62580@plan-b.pwste.edu.pl> <20170109221712.GA49594@plan-b.pwste.edu.pl> From: Ian FREISLICH Message-ID: <1397ba00-3ebf-28fb-4f06-f026899865bb@capeaugusta.com> Date: Mon, 9 Jan 2017 22:01:21 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170109221712.GA49594@plan-b.pwste.edu.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 03:01:24 -0000 On 01/09/17 17:17, Marek Zarychta wrote: > On Mon, Jan 09, 2017 at 09:58:38PM +0100, Kristof Provost wrote: >> On 9 Jan 2017, at 18:25, Marek Zarychta wrote: >>> On Sun, Jan 08, 2017 at 07:08:10PM +0100, Kristof Provost wrote: >>>> On 8 Jan 2017, at 15:55, Marek Zarychta wrote: >>>> The problem description doesn=E2=80=99t ring any bells with me, but I= =E2=80=99m >>>> also >>>> not sure > >> I=E2=80=99ve fully understood it. Can you document a mi= nimal reproduction >>>> scenario, >>>> with a pf.conf and perhaps network captures documenting the problem? >>>> >>>> There=E2=80=99s certainly not been a conscious decision to break UDP >>>> reply-to. >>>> >>> Let me apologize, the problem wasn't previously properly identified. >>> It >>> seems to be more problem of UDP protocol implementation than PF issue. >>> UDP sockets are opened and bound to address of the outgoing interface >>> (interface which has a route to the client). Because the socket is not >>> bound to the incoming interface, the PF reply-to rules couldn't be >>> evaluated. By the way, TCP sockets are bound to the interface where >>> the >>> traffic arrives and everything works fine. >>> This machine is i386 running 11.0-STABLE r311772 >>> >>> The problem remains unresolved. Are there any corresponding sysctls >>> correcting this behavior and enabling the opportunity to use PF >>> assisted >>> symmetric routing scenario again? >>> >> How are your UDP listen sockets set up? >> Are they bound to a specific interface, or are they listening on >> 0.0.0.0? > Yes, socket is listening on 0.0.0.0, the client from outside network is > initiating connection and initiating packet arrives on interface B, > which is supposed only to communicate with devices on its own network > (no additional routes go via this interface), so normally the reply > would be passed via interface A having default gateway in scope and > communication would fail. > With the assistance of PF reply-to rule, TCP services are able to pass > reply from interface B via other, second gateway: reply-to (B GW2). Are you saying that your network looks approximately like this and there=20 is no route to the client network where X resides on your server: iface-A----GW1 iface-B--_local network_--GW2--_client X_ Client X originates a UDP "connection" to B and that return traffic to X=20 leaves interface A despite your reply-to rule. I would be very interested to know: 1. whether the reply-to rule actually matches on the inbound traffic. =20 You can make the rule log and tcpdump on the pflog0 interface. I=20 believe the -e option to tcpdump will show the rule that matched. 2. the output of "pfctl -s sta |grep IP_of_X" 3. what software you're using for your UDP server. I can try to=20 reproduce your issue. Ian > This functionality is currently broken for any UDP service, because UDP > sockets are always opened on supposed_to_be_outgoing interface A and > bound to the address of this interface, which is considered good from > routing table perspective, but silently breaks PF reply-to for UDP. > > When the machine was running 9-STABLE reply-to had successfully been > used to assist both TCP and UDP driven services. > > Is anyone reading this list still using reply-to rule for routing UDP > traffic back via incoming interface? > > Maybe currently, the better place to discuss this questions would be > freebsd-net, but the thread was initiated here. > >> I=E2=80=99m afraid I=E2=80=99m still struggling to understand what your = setup is, >> what you=E2=80=99re >> expecting to see and what you=E2=80=99re seeing instead. >> >> Regards, >> Kristof > > --=20 =20 Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the system manager.= =20 This message contains confidential information and is intended only for the= =20 individual named. If you are not the named addressee you should not=20 disseminate, distribute or copy this e-mail. Please notify the sender=20 immediately by e-mail if you have received this e-mail by mistake and=20 delete this e-mail from your system. If you are not the intended recipient= =20 you are notified that disclosing, copying, distributing or taking any=20 action in reliance on the contents of this information is strictly=20 prohibited. From owner-freebsd-pf@freebsd.org Tue Jan 10 08:29:02 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51C25CA9F32 for ; Tue, 10 Jan 2017 08:29:02 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [88.199.43.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "plan-b.pwste.edu.pl" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D189611AD for ; Tue, 10 Jan 2017 08:29:01 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPS id v0A8SuPA094345 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 10 Jan 2017 09:28:56 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.15.2/8.15.2/Submit) id v0A8Stqk094340; Tue, 10 Jan 2017 09:28:55 +0100 (CET) (envelope-from zarychtam) Date: Tue, 10 Jan 2017 09:28:55 +0100 From: Marek Zarychta To: Ian FREISLICH Cc: freebsd-pf@freebsd.org Subject: Re: udp - weird behavior of reply-to Message-ID: <20170110082855.GA90712@plan-b.pwste.edu.pl> References: <20170108145532.GA17695@plan-b.pwste.edu.pl> <20170109172519.GA62580@plan-b.pwste.edu.pl> <20170109221712.GA49594@plan-b.pwste.edu.pl> <1397ba00-3ebf-28fb-4f06-f026899865bb@capeaugusta.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline In-Reply-To: <1397ba00-3ebf-28fb-4f06-f026899865bb@capeaugusta.com> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 08:29:02 -0000 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 09, 2017 at 10:01:21PM -0500, Ian FREISLICH wrote: > On 01/09/17 17:17, Marek Zarychta wrote: > > On Mon, Jan 09, 2017 at 09:58:38PM +0100, Kristof Provost wrote: > >> On 9 Jan 2017, at 18:25, Marek Zarychta wrote: > >>> On Sun, Jan 08, 2017 at 07:08:10PM +0100, Kristof Provost wrote: > >>>> On 8 Jan 2017, at 15:55, Marek Zarychta wrote: > >>>> The problem description doesn=E2=80=99t ring any bells with me, but = I=E2=80=99m > >>>> also > >>>> not sure > >> I=E2=80=99ve fully understood it. Can you document a = minimal reproduction > >>>> scenario, > >>>> with a pf.conf and perhaps network captures documenting the problem? > >>>> > >>>> There=E2=80=99s certainly not been a conscious decision to break UDP > >>>> reply-to. > >>>> > >>> Let me apologize, the problem wasn't previously properly identified. > >>> It > >>> seems to be more problem of UDP protocol implementation than PF issue. > >>> UDP sockets are opened and bound to address of the outgoing interface > >>> (interface which has a route to the client). Because the socket is not > >>> bound to the incoming interface, the PF reply-to rules couldn't be > >>> evaluated. By the way, TCP sockets are bound to the interface where > >>> the > >>> traffic arrives and everything works fine. > >>> This machine is i386 running 11.0-STABLE r311772 > >>> > >>> The problem remains unresolved. Are there any corresponding sysctls > >>> correcting this behavior and enabling the opportunity to use PF > >>> assisted > >>> symmetric routing scenario again? > >>> > >> How are your UDP listen sockets set up? > >> Are they bound to a specific interface, or are they listening on > >> 0.0.0.0? > > Yes, socket is listening on 0.0.0.0, the client from outside network is > > initiating connection and initiating packet arrives on interface B, > > which is supposed only to communicate with devices on its own network > > (no additional routes go via this interface), so normally the reply > > would be passed via interface A having default gateway in scope and > > communication would fail. > > With the assistance of PF reply-to rule, TCP services are able to pass > > reply from interface B via other, second gateway: reply-to (B GW2). >=20 > Are you saying that your network looks approximately like this and there= =20 > is no route to the client network where X resides on your server: >=20 > iface-A----GW1 > iface-B--_local network_--GW2--_client X_ >=20 > Client X originates a UDP "connection" to B and that return traffic to X= =20 > leaves interface A despite your reply-to rule. >=20 > I would be very interested to know: >=20 > 1. whether the reply-to rule actually matches on the inbound traffic. =20 > You can make the rule log and tcpdump on the pflog0 interface. I=20 > believe the -e option to tcpdump will show the rule that matched. >=20 > 2. the output of "pfctl -s sta |grep IP_of_X" >=20 > 3. what software you're using for your UDP server. I can try to=20 > reproduce your issue. >=20 > Ian Both interfaces have public IP addresses, server has a route to client via GW1, client originates connection to B via GW2. TCP replies originate from socket associated with (bound to) interface B so reply-to works as expected and client is able to connect to both interfaces simultaneously. Corresponding PF states are shown below all tcp ADDR_A:22 <- CLIENT_ADDR:57598 ESTABLISHED:ESTABLISHED all tcp ADDR_B:22 <- CLIENT_ADDRR:58856 ESTABLISHED:ESTABLISHED UDP datagrams never originate from socket B ignoring client effort to use socket associated with interface B, what was investigated using sockstat. Server always tries to respond via interface A and simply create new PF state as shown below.=20 all udp ADDR_B:1194 <- CLIENT_ADDRR:35607 NO_TRAFFIC:SINGLE all udp ADDR_A:1194 -> CLIENT_ADDRR:35607 SINGLE:NO_TRAFFIC This is also seen by pflog: 06:38:52.195266 rule 487/0(match): pass in on B: CLIENT_ADDRR.35607 > ADDR_B.1194: UDP, length 42 06:38:52.196970 rule 488/0(match): pass out on A: ADDR_A.1194 > CLIENT_ADDRR.35607: UDP, length 54 Rules 487 and 488 are shown below: pass in log quick on $B \ reply-to ( $B $GW2 ) \ inet proto udp \ from any \ to ($ext_if_2:0) port $udp_services \ keep state pass out log quick on $A proto udp \ from any to any \ keep state =20 Successful setup has been previously used to allow client X use address of interface B as OpenVPN remote address. The scenario could be reproduced simply using netcat as a server and client: nc -u -l 1194, nc -u ADDR_B 1194. =20 >=20 > > This functionality is currently broken for any UDP service, because UDP > > sockets are always opened on supposed_to_be_outgoing interface A and > > bound to the address of this interface, which is considered good from > > routing table perspective, but silently breaks PF reply-to for UDP. > > > > When the machine was running 9-STABLE reply-to had successfully been > > used to assist both TCP and UDP driven services. > > > > Is anyone reading this list still using reply-to rule for routing UDP > > traffic back via incoming interface? > > > > Maybe currently, the better place to discuss this questions would be > > freebsd-net, but the thread was initiated here. > > > >> I=E2=80=99m afraid I=E2=80=99m still struggling to understand what you= r setup is, > >> what you=E2=80=99re > >> expecting to see and what you=E2=80=99re seeing instead. > >> > >> Regards, > >> Kristof > > > > >=20 >=20 > --=20 > =20 >=20 > Cape Augusta Digital Properties, LLC a Cape Augusta Company >=20 > *Breach of confidentiality & accidental breach of confidentiality * >=20 > This email and any files transmitted with it are confidential and intende= d=20 > solely for the use of the individual or entity to whom they are addressed= =2E=20 > If you have received this email in error please notify the system manager= =2E=20 > This message contains confidential information and is intended only for t= he=20 > individual named. If you are not the named addressee you should not=20 > disseminate, distribute or copy this e-mail. Please notify the sender=20 > immediately by e-mail if you have received this e-mail by mistake and=20 > delete this e-mail from your system. If you are not the intended recipien= t=20 > you are notified that disclosing, copying, distributing or taking any=20 > action in reliance on the contents of this information is strictly=20 > prohibited. > _______________________________________________ > freebsd-pf@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >=20 --=20 Marek Zarychta --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlh0m0QACgkQdZ/s//1S jSy76AgAtJLxOOy0k6GhvgDggr0a+QzYJEKTnHN6qZFAzwDkGdWrhRziJP2B1hBI 3eNoTRi4yat+YEa33/iktWFeV6oS7ro2IbQtCFucFmjYS5f0QixMk+rI3rVLRG7u ZldQy+9u3eDu53cCJgTbtgwm0yW2l0E9LviH9ICibksmHB3bJqsZxf3HzTqqvVTr A417nNx2MPyS2KR1O/wJO0N32qI53ETO3iZpySvBorsCTowBEFVRyVsvCcRqPPcQ AWufCKS/gDmHFQiqOJw9ToOfwVTSrFzrYdSfdX2JUccOrBaBHkkrkRazzQzSPBON ITRLJ9C94c/erOt8FlD67Cwv9TcAlg== =23De -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From owner-freebsd-pf@freebsd.org Wed Jan 11 00:58:19 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8685DCA8588 for ; Wed, 11 Jan 2017 00:58:19 +0000 (UTC) (envelope-from usr.src.linux@gmail.com) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 237B61608 for ; Wed, 11 Jan 2017 00:58:19 +0000 (UTC) (envelope-from usr.src.linux@gmail.com) Received: by mail-wm0-x22c.google.com with SMTP id c85so144186668wmi.1 for ; Tue, 10 Jan 2017 16:58:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5o9Td+BetD1ZaMhw49lPBFeNx9U5XrV650BCC7UIdqk=; b=kvwBPrLVjPwlV2IYTcPirAX20xMhvJeMgR4f7wqQeYJ+LBn0+1BPrILozRYyJey22l 8G3oV0ir81ApwIZhMhdv7P9EYdf/dXdJLdJMlA/+H+sWo5udoP6WD9LOoJF7vFfYHYi7 RjyBmGUtoU7mjudOyS9cTZlqasC9DpNAmQ16kNSUdqgfPBIjbM8MFes7AEt2hKD8kpD7 9gKXl38S3NfvmNvnR5P7V7agHbsnNgb9fMGupe2YkyF0c7xoA9ZnJbPWakw/04GsI6VJ PiU1LiotJTCDKSGwca+zGoxiccLk9ec+tyu3XlxZkWcjV/pwt3nK8AcND7tAQ2+pOzUS 0eAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5o9Td+BetD1ZaMhw49lPBFeNx9U5XrV650BCC7UIdqk=; b=o5MAZpjoiNO/Gjw9Z55lKP9II3BMCCnYSi65p9Z9Tm63AVODvZu+a1l+yb8Xc2JDCM NPLTudehBaJp7Yigtdy6w9f3/V8lgH+BuMZVWuya176jJFy49YWk5fG9b1JKwT+Roxpa 34F5MrLwbJhl1q77Xky+JZ3HH1mwGsLy+GXk4YDN9N9VAVxlk0kpJpvIYfUmxC8qoug7 t/1VS3a3FqmhqXbFqObsT66e3YhMmefljgYc8y7zsrtjPR09ovBZ8MF7laRNQX0XDnVW pTIm1ikRmpIZewnHUZEorWXNtH3wHQj+XmqJPYEiqLJ0Kk1ay61KNpNq6WuNr3OJUhE0 xYkQ== X-Gm-Message-State: AIkVDXJ3INdWYz7FXJyQqREHOyuNNqTvcup2ByB1S4f3ctfOMBvOa2M6zaNquLToZ0tD3RQjpqyUBslndjmvxw== X-Received: by 10.28.182.6 with SMTP id g6mr2679386wmf.11.1484096296321; Tue, 10 Jan 2017 16:58:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.236.133 with HTTP; Tue, 10 Jan 2017 16:58:15 -0800 (PST) From: Harry Duncan Date: Wed, 11 Jan 2017 00:58:15 +0000 Message-ID: Subject: interface definition with aliases To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 00:58:19 -0000 Hi Guys, I get my net connection to my freebsd box by pppoe. I have a /29 allocation, so I have to add my additional IP's at the public interface on my bsd box, so I add them with ifconfig tun0 alias 121.171.163.226 netmask 255.255.255.255 181.191.100.212 and I end up with a tun0 looking like: tun0: flags=8051 metric 0 mtu 1492 options=80000 inet 121.171.163.225 --> 181.191.100.212 netmask 0xffffffff inet 121.171.163.226 --> 181.191.100.212 netmask 0xffffffff inet 121.171.163.227 --> 181.191.100.212 netmask 0xffffffff inet 121.171.163.228 --> 181.191.100.212 netmask 0xffffffff inet 121.171.163.229 --> 181.191.100.212 netmask 0xffffffff inet 121.171.163.230 --> 181.191.100.212 netmask 0xffffffff nd6 options=21 groups: tun Opened by PID 4207 In the normal course of events, with a single wan ip, I just declare ext_if = "tun0" in pf.conf and it resolves to the wan ip. What I want to be able to do here is reference specific aliases in rules, so for example, port forward port 22 on .225 to one lan host, port forward the same port on .226 to another lan host I also want to direct all traffic out from specific lan hosts to go out on specific ip addresses and not randomly across the range. I have accomplished this before with intefrace aliases where pppoe has not been used, but am stuck conceptually on how to implement this where the ip aliases are all on the same interface. Anyone got any thoughts if this is going to be possible? My alternate course of action will be to try and bring up a tun device for each of the aliases with a different ppp dialer, just not sure routing wise if that is going to work so I'm just curious to know if you guys think it can be accomplished with the above? Thanks, Harry. From owner-freebsd-pf@freebsd.org Wed Jan 11 10:24:43 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DF21CAAE38 for ; Wed, 11 Jan 2017 10:24:43 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5322B1FE8 for ; Wed, 11 Jan 2017 10:24:42 +0000 (UTC) (envelope-from ml@my.gd) Received: by mail-ua0-x231.google.com with SMTP id i68so403143254uad.0 for ; Wed, 11 Jan 2017 02:24:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=my-gd.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gDaAUbixpsMvFxn0BQeRqB9l2LiZuAkd66xbrc231BI=; b=r7ejv70l+1vpUO3d9+vDJ31a7lgV32COIGcBJaFdZC3R4KUdsBLKhVH8RHfi9Oi9Vt +/G8uceB7pz+RWlKvFn7QMo7QbOLfkiQ/Tw7qKs3BFxlvK/ti8CqsasxJHP1ZeeAFcKL eUUl0d/+mnARdcttVx2y4wsDkmA/2A3Ezp2IKf4Tt3tYt+KoWnK2zbKptZR+5RMpls3O OtolMi6/7hfcg4y3srx/LMZMjON/gP28mwpAm8AB67dVfqJN4csb0jwfd9wPRgItvmvd UPm77R1Ojo5XztGr7qWgdNBesjOOhAmqBTkQKRkRG23matQKTJJwdM8yl6cW7/nBF55S qxQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gDaAUbixpsMvFxn0BQeRqB9l2LiZuAkd66xbrc231BI=; b=Px8Xn21QKx4u+TwfGIS+kFF2FrDclEf+Nq1xRaCf6KErUhKMCY0E8LP9chj5vDipnD I2W4Gsdz1AeXWlnlTYHF1c5DvHgHHTpW7HiWlIypjuOQM3EQbYu3R3JA9hjMyzIZKhZn p2eMiJ2E4TrLjaNwwYET3UrvR2jaaoOggbm4Z3G8hU3qaS/hYXd7j8gFmbZZlWYQkrQ+ UcelT9wx4jbYLbKeDnNYAadFCZmtMFd9WlKCDZnkMv82eM2YNYdXCJYV47l9Ivxvv4b+ g3IsK2meaW61ud3h+UJsUobZ3qy5ae6KBQAYWEKXTJY/XaBc65rhlL6YNDuuFs19HZHY UdvQ== X-Gm-Message-State: AIkVDXLeVvBJA28EwfTUIO25sR0TCr8etNKLvoa/Yglg2WrqFctxH0gpBxTU2QScAnCadWeppWq6jhdoYG/O6g== X-Received: by 10.176.0.181 with SMTP id 50mr4190016uaj.103.1484130282046; Wed, 11 Jan 2017 02:24:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.48.213 with HTTP; Wed, 11 Jan 2017 02:24:41 -0800 (PST) In-Reply-To: References: From: Damien Fleuriot Date: Wed, 11 Jan 2017 11:24:41 +0100 Message-ID: Subject: Re: interface definition with aliases To: Harry Duncan Cc: freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 10:24:43 -0000 On 11 January 2017 at 01:58, Harry Duncan wrote: > Hi Guys, > > I get my net connection to my freebsd box by pppoe. I have a /29 > allocation, so I have to add my additional IP's at the public interface on > my bsd box, so I add them with > > ifconfig tun0 alias 121.171.163.226 netmask 255.255.255.255 181.191.100.212 > > and I end up with a tun0 looking like: > > tun0: flags=8051 metric 0 mtu 1492 > options=80000 > inet 121.171.163.225 --> 181.191.100.212 netmask 0xffffffff > inet 121.171.163.226 --> 181.191.100.212 netmask 0xffffffff > inet 121.171.163.227 --> 181.191.100.212 netmask 0xffffffff > inet 121.171.163.228 --> 181.191.100.212 netmask 0xffffffff > inet 121.171.163.229 --> 181.191.100.212 netmask 0xffffffff > inet 121.171.163.230 --> 181.191.100.212 netmask 0xffffffff > nd6 options=21 > groups: tun > Opened by PID 4207 > > In the normal course of events, with a single wan ip, I just declare ext_if > = "tun0" in pf.conf and it resolves to the wan ip. > > What I want to be able to do here is reference specific aliases in rules, > so for example, port forward port 22 on .225 to one lan host, port forward > the same port on .226 to another lan host > > I also want to direct all traffic out from specific lan hosts to go out on > specific ip addresses and not randomly across the range. > > I have accomplished this before with intefrace aliases where pppoe has not > been used, but am stuck conceptually on how to implement this where the ip > aliases are all on the same interface. > > Anyone got any thoughts if this is going to be possible? > > My alternate course of action will be to try and bring up a tun device for > each of the aliases with a different ppp dialer, just not sure routing wise > if that is going to work so I'm just curious to know if you guys think it > can be accomplished with the above? > Heya Harry, You could always create macros in your pf.conf, like so : ip1="1.2.3.4" ip2="2.3.4.5" ip3="3.4.5.6" You can then reference them in your rules : pass in quick on $tun0 inet proto tcp from to $tun0:0 port 10 $tcpflags # this references only your primary IP on $tun0 pass in quick on $tun0 inet proto tcp from to $ip1 port 11 $tcpflags # and these applies to your macros pass in quick on $tun0 inet proto tcp from to $ip2 port 12 $tcpflags # ditto pass in quick on $tun0 inet proto tcp from to $ip3 port 13 $tcpflags # ditto Once you've set up your macros, you're free to do whatever you like. # Redirect SSH to public IP 1 to an internal host : rdr pass on $tun0 inet proto tcp from to $ip1 port 22 -> 192.168.0.1 # NAT outgoing from internal host to a specific tun0 IP : nat pass on $tun0 inet from 192.168.0.1 to any -> $ip3 I hope I did not misunderstand your question and that is what you were looking for. From owner-freebsd-pf@freebsd.org Fri Jan 13 02:06:35 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C46A5CADA4F for ; Fri, 13 Jan 2017 02:06:35 +0000 (UTC) (envelope-from simon@optinet.com) Received: from cobra.acceleratedweb.net (cobra-gw.acceleratedweb.net [207.99.79.37]) by mx1.freebsd.org (Postfix) with SMTP id 5CEB713C8 for ; Fri, 13 Jan 2017 02:06:34 +0000 (UTC) (envelope-from simon@optinet.com) Received: (qmail 39417 invoked by uid 110); 13 Jan 2017 01:59:52 -0000 Received: from ool-43549c41.dyn.optonline.net (HELO desktop1) (simon@optinet.com@67.84.156.65) by cobra.acceleratedweb.net with SMTP; 13 Jan 2017 01:59:52 -0000 From: "Simon" To: "freebsd-pf@freebsd.org" Date: Thu, 12 Jan 2017 20:59:53 -0500 Priority: Normal X-Mailer: PMMail 2000 Professional (2.20.2717) For Windows 2000 (5.1.2600;3) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Treating Multiple Virtual IPs as one X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 02:06:35 -0000 Hello, I am trying to rate limit/control access to a port across multiple virtual IPs or aliases using max-src-conn and max-src-conn-rate. Problem arises when attacker floods connections to the same port across many IPs listening on the same port. Is it possible to tell PF to treat connections to the same port across multiple IPs assigned to the same NIC in the instances of max-src-conn-rate ? In other words, I want connections made to port XX on x.x.x.1, x.x.x.2, etc... count toward the same counter using max-src-conn-rate and max-src-conn. By default, each IP tracks own counter and this defeats the purpose of my rate limiting for a port. Couldn't find this in the manual. Hard to imagine this is a very unique setup. Thanks, Simon From owner-freebsd-pf@freebsd.org Fri Jan 13 21:54:44 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA5DECAE2A3 for ; Fri, 13 Jan 2017 21:54:44 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 773301CD4 for ; Fri, 13 Jan 2017 21:54:44 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [10.0.2.164] (ptr-8ripyyglt8s3i9mswf7.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:912d:413e:650e:d23]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id BBF1B35908; Fri, 13 Jan 2017 22:54:41 +0100 (CET) From: "Kristof Provost" To: "Marek Zarychta" Cc: freebsd-pf@freebsd.org Subject: Re: udp - weird behavior of reply-to Date: Fri, 13 Jan 2017 22:54:40 +0100 Message-ID: In-Reply-To: <20170109172519.GA62580@plan-b.pwste.edu.pl> References: <20170108145532.GA17695@plan-b.pwste.edu.pl> <20170109172519.GA62580@plan-b.pwste.edu.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6072) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 21:54:44 -0000 On 9 Jan 2017, at 18:25, Marek Zarychta wrote: > On Sun, Jan 08, 2017 at 07:08:10PM +0100, Kristof Provost wrote: >> On 8 Jan 2017, at 15:55, Marek Zarychta wrote: >> The problem description doesn’t ring any bells with me, but I’m >> also >> not sure >> I’ve fully understood it. Can you document a minimal reproduction >> scenario, >> with a pf.conf and perhaps network captures documenting the problem? >> >> There’s certainly not been a conscious decision to break UDP >> reply-to. >> > > Let me apologize, the problem wasn't previously properly identified. > It > seems to be more problem of UDP protocol implementation than PF issue. > UDP sockets are opened and bound to address of the outgoing interface > (interface which has a route to the client). Because the socket is not > bound to the incoming interface, the PF reply-to rules couldn't be > evaluated. By the way, TCP sockets are bound to the interface where > the > traffic arrives and everything works fine. > This machine is i386 running 11.0-STABLE r311772 > > The problem remains unresolved. Are there any corresponding sysctls > correcting this behavior and enabling the opportunity to use PF > assisted > symmetric routing scenario again? > Thinking about this a bit more, I think the behaviour you see is entirely correct and expected. We’re talking about datagram sockets, and as far as the kernel is concerned there’s no relationship between the packet you’ve just received from address X and the packet you send to host X. There’s no established connection. As a result it’s entirely free to choose its source address: you’re simply telling the kernel “Send this data to X”, you’re not adding “it’s from Y”. If you want this to behave differently I think you’ll have to convince your application to open a socket per interface (binding it to that interface), and reply using the correct socket. Regards, Kristof From owner-freebsd-pf@freebsd.org Sat Jan 14 08:26:49 2017 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67FDBCAE7DD for ; Sat, 14 Jan 2017 08:26:49 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [88.199.43.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "plan-b.pwste.edu.pl" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E21C105A; Sat, 14 Jan 2017 08:26:48 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPS id v0E8QcUr088073 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 14 Jan 2017 09:26:38 +0100 (CET) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.15.2/8.15.2/Submit) id v0E8QcRn088071; Sat, 14 Jan 2017 09:26:38 +0100 (CET) (envelope-from zarychtam) Date: Sat, 14 Jan 2017 09:26:38 +0100 From: Marek Zarychta To: Kristof Provost Cc: freebsd-pf@freebsd.org Subject: Re: udp - weird behavior of reply-to Message-ID: <20170114082638.GA84804@plan-b.pwste.edu.pl> References: <20170108145532.GA17695@plan-b.pwste.edu.pl> <20170109172519.GA62580@plan-b.pwste.edu.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 08:26:49 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 13, 2017 at 10:54:40PM +0100, Kristof Provost wrote: > On 9 Jan 2017, at 18:25, Marek Zarychta wrote: > > On Sun, Jan 08, 2017 at 07:08:10PM +0100, Kristof Provost wrote: > >> On 8 Jan 2017, at 15:55, Marek Zarychta wrote: > >> The problem description doesn=E2=80=99t ring any bells with me, but I= =E2=80=99m=20 > >> also > >> not sure > >> I=E2=80=99ve fully understood it. Can you document a minimal reproduc= tion > >> scenario, > >> with a pf.conf and perhaps network captures documenting the problem? > >> > >> There=E2=80=99s certainly not been a conscious decision to break UDP= =20 > >> reply-to. > >> > > > > Let me apologize, the problem wasn't previously properly identified. = =20 > > It > > seems to be more problem of UDP protocol implementation than PF issue. > > UDP sockets are opened and bound to address of the outgoing interface > > (interface which has a route to the client). Because the socket is not > > bound to the incoming interface, the PF reply-to rules couldn't be > > evaluated. By the way, TCP sockets are bound to the interface where=20 > > the > > traffic arrives and everything works fine. > > This machine is i386 running 11.0-STABLE r311772 > > > > The problem remains unresolved. Are there any corresponding sysctls > > correcting this behavior and enabling the opportunity to use PF=20 > > assisted > > symmetric routing scenario again? > > > Thinking about this a bit more, I think the behaviour you see is=20 > entirely > correct and expected. We=E2=80=99re talking about datagram sockets, and = as=20 > far as the > kernel is concerned there=E2=80=99s no relationship between the packet=20 > you=E2=80=99ve just > received from address X and the packet you send to host X. There=E2=80=99= s no > established connection. As a result it=E2=80=99s entirely free to choose = its=20 > source > address: you=E2=80=99re simply telling the kernel =E2=80=9CSend this data= to X=E2=80=9D,=20 > you=E2=80=99re not > adding =E2=80=9Cit=E2=80=99s from Y=E2=80=9D. >=20 > If you want this to behave differently I think you=E2=80=99ll have to con= vince=20 > your > application to open a socket per interface (binding it to that=20 > interface), and > reply using the correct socket. >=20 Let me apologize once again. It was application (OpenVPN) issue. After upgrade to newer version, its behavior changed. While the daemon is run in "multihome" mode it should reply with socket address of the interface, which the client originates to. The daemon was misconfigured because while running dual stack IPv4/IPv6 multihomed instance it was trying to respond with IPv4-mapped IPv6 address thus not even evaluating IP_RECVDSTADDR option. Changing configuration option "proto" from "udp" to "udp4" did the job.=20 Netcat couldn't be used in reproduction scenario, as simply app beeing completely unaware of the destination address of the received datagram (not evaluating the IP_RECVDSTADDR socket option at all). Concluding and closing this thread:=20 PF reply-to for UDP protocol still works great!=20 God bless the people keeping code up to date!=20 Thank all trying to help and figure out my weird misconfiguration case. =20 --=20 Marek Zarychta --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAlh54LsACgkQdZ/s//1S jSz+qgf6AgRN4IZJP0K0LGJSUba+UjMjoPk5WIU0jJh+WGm7e9DrmClly+mh0UGg NdsizyCbau1wxFCQl/51S8ermhz4RgcN8cee4gG74b0V3XgYnRD/KeRWKybeSQtq lao7eMNJ5NOvWlK5P5+x4KfocEvH+jcaGEMzLquTSXV8TZY88pgkFIglslUD2lAo RYhfspahGbRUKlIk1c3jIaIVipktUnj4rwOReRBWAgj2swm3v+tJiAe5x74RtwJy q/kU+yJUuBXoiEDRcPKqWYOwDlp4nArahQUdwsWUdRB/A2utnU7wmsZ1EdAQE9aw EHSffSlIgQ8yw/smfb93rNKpVbWM2w== =Nkt4 -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE--