From owner-freebsd-pf@freebsd.org Tue Feb 25 19:50:16 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 939EA23D994 for ; Tue, 25 Feb 2020 19:50:16 +0000 (UTC) (envelope-from kisscoolandthegangbang@hotmail.fr) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-oln040092074037.outbound.protection.outlook.com [40.92.74.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48RqKL1QZcz4LmN for ; Tue, 25 Feb 2020 19:50:13 +0000 (UTC) (envelope-from kisscoolandthegangbang@hotmail.fr) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jWz2Zu2U3cPyuAOeYbW54HxBGgSfZjvvI581H7N22QyrzuUPj8ao4EAzvOfY/QyWvkQLAYG2SB4wHfnifd3GdmHf4CdTHqAYg3CVU2iHC+3ZTTj8Oej+lmsThTNfE4BIkCb1cYZRNyhWpjVx9cNFiIXAhMm+Kml4WRcPR9kEh7NFRMZRQahyLmeR90KHGW5TWGKLQDHwbRC+1Vm+jkt3/khN4I9DwW2B6oN4SeXTpQlYOyEW+eYXv8lCVVKz67vmWINhB65SKwPqt03UDuMOQSBa+hI353+x8ppq14EPZngOjTWMYVgNI0mtwUBZBXwfQX8m6Q9tE1XNYTx+1t6y5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JphQHs2xqdscIil8K0SmrBlH5H6DAVXNyYGFKysZsVs=; b=AfqtwIxcD1EAKl/VJFpThKf0Xnxh2NZbhP2/Yvhrn9zKlttpvGFiWVAs/cZxrB0cHcajhNGffY1nU9prGwH1OjtB3Mad0sExtU1PmXlUfPUZZkfxCW5HCSTA3ZC5SgUd0zqcht1F8qugbGsmZOxPxE3zJ4zpjxtTA5Aa6HiwM76nHAk8JlV7/YgKhVSE5aLCDhcrW8mx5FDcoGWjDvzOrq0NdcfutHYYr+DqxxrW1lq2jIigTD81VUR64npvwqtXNECAB5KETDAol8/nCuxbAslelhToWLoIQcLaDxoI59jG46bK9g7yul1zhAS9eaJKwvhqGcySZ/SSjhcfDeUdDw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from VI1EUR04FT037.eop-eur04.prod.protection.outlook.com (10.152.28.58) by VI1EUR04HT164.eop-eur04.prod.protection.outlook.com (10.152.28.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.19; Tue, 25 Feb 2020 19:50:11 +0000 Received: from VE1PR03MB5629.eurprd03.prod.outlook.com (10.152.28.51) by VI1EUR04FT037.mail.protection.outlook.com (10.152.29.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Tue, 25 Feb 2020 19:50:11 +0000 Received: from VE1PR03MB5629.eurprd03.prod.outlook.com ([fe80::157c:e8c6:4788:a521]) by VE1PR03MB5629.eurprd03.prod.outlook.com ([fe80::157c:e8c6:4788:a521%7]) with mapi id 15.20.2750.021; Tue, 25 Feb 2020 19:50:11 +0000 Received: from mail.lacabanedeladmin.trickip.net (93.1.37.139) by LNXP265CA0007.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Tue, 25 Feb 2020 19:50:11 +0000 Received: from slackstro.home.lan ([172.16.93.12]) (authenticated bits=0) by mail.lacabanedeladmin.trickip.net (8.15.2/8.15.2) with ESMTPSA id 01PJo9PT026250 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 25 Feb 2020 20:50:09 +0100 (CET) (envelope-from kisscoolandthegangbang@hotmail.fr) From: kaycee gb To: "freebsd-pf@freebsd.org" Subject: usage of rdr and pass validation Thread-Topic: usage of rdr and pass validation Thread-Index: AQHV7BTK93gfeOMNTUCzAPORpfn2zQ== Date: Tue, 25 Feb 2020 19:50:11 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LNXP265CA0007.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::19) To VE1PR03MB5629.eurprd03.prod.outlook.com (2603:10a6:803:11e::30) x-incomingtopheadermarker: OriginalChecksum:FE136F6C10B0EE3F4052D75CC4600FD4392C796AC32ABEBD54BC7A556C6E3420; UpperCasedChecksum:D5AF5567410D842805D7350E1BC8D2CE74CAB3EBE1F6E916622F2BFAAFD600B8; SizeAsReceived:7763; Count:49 x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; x86_64-unknown-linux-gnu) x-tmn: [gv9Sm182wi9mYL6QeHEgOeibdZtxVqk2] x-microsoft-original-message-id: <20200225205009.626863dd@slackstro.home.lan> x-ms-publictraffictype: Email x-incomingheadercount: 49 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 62036127-edf9-4b84-951a-08d7ba2becaf x-ms-traffictypediagnostic: VI1EUR04HT164: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w0/KGNwiZirIWCnm5bGlJtIFTbjKn9q6EeT5xYa/eC/K/B4K/M1TdNDHUOzjcqkSWO+30hBDFIm/2QytzHjQj/iMY7dm+Usp0Lslckh9OGZbYBnTvmH4DVUxfYpeYSga9Ja9CARgQ2HsGKr80KBuPMJyFdewT84iESmitrElHFkzN+KR0QJnUWelDvRzqe0h x-ms-exchange-antispam-messagedata: MCvpc+8UQ/Lj/cVH3f8nhklgHWJNzSQH/PHbF2fjyu4yDG1EHqX1p0RY4q6bmZFlXZdMW9zmrSnKTCu+v82KQg+VRBXWyPvmgWaf3TpmwgXADHM1LUnIaPPl3EnzipOlhwf5Y41tDmFx/AitjOYlJQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 62036127-edf9-4b84-951a-08d7ba2becaf X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2020 19:50:11.6612 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1EUR04HT164 X-Rspamd-Queue-Id: 48RqKL1QZcz4LmN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=hotmail.fr; spf=pass (mx1.freebsd.org: domain of kisscoolandthegangbang@hotmail.fr designates 40.92.74.37 as permitted sender) smtp.mailfrom=kisscoolandthegangbang@hotmail.fr X-Spamd-Result: default: False [-3.80 / 15.00]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; FREEMAIL_FROM(0.00)[hotmail.fr]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[hotmail.fr,none]; RCVD_IN_DNSWL_NONE(0.00)[37.74.92.40.list.dnswl.org : 127.0.3.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; IP_SCORE(0.00)[ipnet: 40.64.0.0/10(-3.83), asn: 8075(-3.12), country: US(-0.05)]; RECEIVED_SPAMHAUS_PBL(0.00)[139.37.1.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[hotmail.fr]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 25 Feb 2020 19:50:16 -0000 Hi, First, sorry english is not my native language. I will try to be as precise= as possible.=20 And also I am not sure it is only pf related. Let me know in this case plea= se. Maybe it would be for net an jail too.=20 So, I have two cases maybe related.=20 First one is for using rdr translation rule.=20 I have a host with FreeBSD 11.3 amd64 hosting some jails. I want to join one service from the outside. Using one rdr rule like this one, all seems t= o work fine. I have acces to the service. > rdr pass on $ext_if inet proto tcp from any to $ext_if port 443 -> > $j_one port 443=20 But in case I want to apply some options to this, I have to split it in 3. = This is the relevant part of my config that makes it work=20 > # Emulate skip on lo0 > pass quick on lo0 from 127.0.0.1 to > 127.0.0.1 > # jail internal comms > pass quick on lo0 from $j_one to $j_one >=20 ># other traffic ( do not know yet why it is necessary and why no interface >specified in mandatory ) > pass in quick proto tcp from any to $j_one port 443 > > # block all on lo0 > block log quick on lo0 > > rdr on $ext_if inet proto tcp from any to $ext_if port 443 -> > $j_one port 443 > pass in quick on $ext_if proto tcp from any to $j_one port 443 See the two lines at the end which are the first two parts. The third part = is the line after the "other traffic comment". After a lot of error and retry, this line have to be wrote like that. I can not add "on lo0" on this line o= r the service is not reachable.=20 I'm using jails since some time now and remember having jail traffic bound = to lo0 before even in my configuration jails have another interface defined (a bridge generally).=20 So I would like to know why isn't it possible to limit more this rule ? I tried all other interfaces present in my system, and that do not work eithe= r. Using tcpdump, I can't see the traffic related to this service on any interface except the external one. It's a little bit strange for me.=20 Finally, I will write another mail for the other case.=20 kaycee, From owner-freebsd-pf@freebsd.org Tue Feb 25 21:43:46 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 8FE1C2414CA for ; Tue, 25 Feb 2020 21:43:46 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48RsrJ1qNPz4RgL for ; Tue, 25 Feb 2020 21:43:43 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 01PLhiZ4051464 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Feb 2020 13:43:51 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: kaycee gb Subject: Re: usage of rdr and pass validation Date: Tue, 25 Feb 2020 13:43:50 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48RsrJ1qNPz4RgL X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of bsd-lists@BSDforge.com has no SPF policy when checking 24.113.41.81) smtp.mailfrom=bsd-lists@BSDforge.com X-Spamd-Result: default: False [-1.14 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[bsd-lists@BSDforge.com]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.74)[-0.743,0]; IP_SCORE(-0.31)[ip: (-0.58), ipnet: 24.113.0.0/16(-0.29), asn: 11404(-0.64), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[BSDforge.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[hotmail.fr]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 25 Feb 2020 21:43:46 -0000 On Tue, 25 Feb 2020 19:50:11 +0000 kaycee gb kisscoolandthegangbang@hotmail= =2Efr said > Hi, >=20 > First, sorry english is not my native language=2E I will try to be as preci= se > as > possible=2E=20 >=20 > And also I am not sure it is only pf related=2E Let me know in this case > please=2E > Maybe it would be for net an jail too=2E=20 >=20 > So, I have two cases maybe related=2E=20 >=20 > First one is for using rdr translation rule=2E=20 > I have a host with FreeBSD 11=2E3 amd64 hosting some jails=2E I want to join > one service from the outside=2E Using one rdr rule like this one, all seems= to > work fine=2E I have acces to the service=2E >=20 > > rdr pass on $ext_if inet proto tcp from any to $ext_if port 443 -> > > $j_one port 443=20 >=20 > But in case I want to apply some options to this, I have to split it in 3= =2E > This > is the relevant part of my config that makes it work=20 >=20 > > # Emulate skip on lo0 > > pass quick on lo0 from 127=2E0=2E0=2E1 to > > 127=2E0=2E0=2E1 > > # jail internal comms > > pass quick on lo0 from $j_one to $j_o= ne > >=20 > ># other traffic ( do not know yet why it is necessary and why no interfa= ce > >specified in mandatory ) > > pass in quick proto tcp from any to $j_one port 443 > > > > # block all on lo0 > > block log quick on lo0 > > > > rdr on $ext_if inet proto tcp from any to $ext_if port 443 -> > > $j_one port 443 > > pass in quick on $ext_if proto tcp from any to $j_one port 44= 3 >=20 > See the two lines at the end which are the first two parts=2E The third par= t > is > the line after the "other traffic comment"=2E After a lot of error and retr= y, > this line have to be wrote like that=2E I can not add "on lo0" on this line= or > the > service is not reachable=2E=20 >=20 > I'm using jails since some time now and remember having jail traffic boun= d > to > lo0 before even in my configuration jails have another interface defined = (a > bridge generally)=2E=20 >=20 > So I would like to know why isn't it possible to limit more this rule ? I > tried all other interfaces present in my system, and that do not work > either=2E > Using tcpdump, I can't see the traffic related to this service on any > interface except the external one=2E It's a little bit strange for me=2E=20 >=20 > Finally, I will write another mail for the other case=2E FWIW I simply add additional lo interfaces (lo0, lo1, lo2, =2E=2E=2E) when I attempt these sort of things=2E As it seems to simplify things in my head=2E For example, rc=2Econf cloned_interfaces=3D"lo1 lo2" ifconfig_lo1=3D"inet 127=2E0=2E0=2E2" ifconfig_lo2=3D"inet 127=2E0=2E0=2E3" This allows me to treat them as any other NIC=2E I route as necessary to my NIC to the outside world; pf=2Econf(5): EXT_ADDR=3D"ou=2Ets=2Eide=2Eip" # contains 127=2E0=2E0=2E0/24 and other trusted IPs=2E Sometimes helpful=2E table persist file "/etc/TRUSTED" set skip on { lo0, lo1, lo2 } # this only represents the rule(s) for lo1 but should be helpful for # additional rules on lo2 (or more) nat pass on re0 from { lo1 } to any -> $EXT_ADDR rdr pass on re0 proto tcp from any to { lo1 } -> $EXT_ADDR block in pass out HTH --Chris >=20 > kaycee, > _______________________________________________ > freebsd-pf@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd=2Eorg" From owner-freebsd-pf@freebsd.org Wed Feb 26 10:32:04 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CDF952537CE for ; Wed, 26 Feb 2020 10:32:04 +0000 (UTC) (envelope-from kisscoolandthegangbang@hotmail.fr) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-oln040092071042.outbound.protection.outlook.com [40.92.71.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48SBtp2dDGz4ZN3 for ; Wed, 26 Feb 2020 10:32:01 +0000 (UTC) (envelope-from kisscoolandthegangbang@hotmail.fr) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M3XVqyQvu6nAKRtj7WOaUeNfx3Og/iMOsTDU4/vrpq5cqqRRFut4CQkOg9H9N2HB9jIR2bSxs2badzP64MXTwL+6vENFYoaThiyoiFcJJQ86t88z/EJW4rsS7TzmSl+YBQLD6ZlSKcWYLhHOjTtEAHfZ+u7pWKXk7a6DC9Skg1r9YeudGKKfajh0aqdz8ixiVnx2j7D5Nu1mdUXFEZfyvm/f+I5lx0sLBAApUbFewvM6kCdMAHnMdM2BVPfeYAVGk9jFRRucr0rLq2HZkjha1WqkPHu44b8YV8EFZFNNRRr9FkMo8ef6bGwbEHCj+P+M8PiO3B0vJAOsYEjm/o37gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9ciaooVidf58cmvymknotdKNtqgLIven6Sy5b6xq7qU=; b=IQ1X19o/SxEU36WtGYK/f9hkYCPgAJVQ4YBBoXmDTNK/5Etw/jU5vTn70orkjrfXbrabuC45Sh7QRQuP8kRHj/JjIPZHPLI/uOPn9RPWNKsvVIF0FGGPTxotHEI/mIOrIiLbqh7+DdGZVkWaLYBLItEdpbu8jahy5FaX8ZpN3f0YXAWau/2ZOd6uZFBeZ/joyNiAszzJ6khwvGTX/lmMNRCJaNIlpVvB3y0V+OjqoirsIF1nOao6bfaHvFgKhpFzImkUFWfYSyhPj+nMUeRoGN6Ch2ic0m9FcvO97rK7nv+XeXE6lg9jXBnDbolbIavaBNabYuOOjyluD7lrgokV6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DB5EUR03FT004.eop-EUR03.prod.protection.outlook.com (2a01:111:e400:7e0a::37) by DB5EUR03HT161.eop-EUR03.prod.protection.outlook.com (2a01:111:e400:7e0a::224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.19; Wed, 26 Feb 2020 10:32:00 +0000 Received: from VE1PR03MB5629.eurprd03.prod.outlook.com (10.152.20.56) by DB5EUR03FT004.mail.protection.outlook.com (10.152.20.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Wed, 26 Feb 2020 10:32:00 +0000 Received: from VE1PR03MB5629.eurprd03.prod.outlook.com ([fe80::157c:e8c6:4788:a521]) by VE1PR03MB5629.eurprd03.prod.outlook.com ([fe80::157c:e8c6:4788:a521%7]) with mapi id 15.20.2750.021; Wed, 26 Feb 2020 10:31:59 +0000 Received: from mail.lacabanedeladmin.trickip.net (93.1.37.139) by AM0PR05CA0058.eurprd05.prod.outlook.com (2603:10a6:208:be::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.18 via Frontend Transport; Wed, 26 Feb 2020 10:31:59 +0000 Received: from slackstro.home.lan ([172.16.93.12]) (authenticated bits=0) by mail.lacabanedeladmin.trickip.net (8.15.2/8.15.2) with ESMTPSA id 01QAVvTP024341 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 26 Feb 2020 11:31:58 +0100 (CET) (envelope-from kisscoolandthegangbang@hotmail.fr) From: kaycee gb To: "freebsd-pf@freebsd.org" Subject: Re: usage of rdr and pass validation Thread-Topic: usage of rdr and pass validation Thread-Index: AQHV7BTK93gfeOMNTUCzAPORpfn2zQ== Date: Wed, 26 Feb 2020 10:31:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM0PR05CA0058.eurprd05.prod.outlook.com (2603:10a6:208:be::35) To VE1PR03MB5629.eurprd03.prod.outlook.com (2603:10a6:803:11e::30) x-incomingtopheadermarker: OriginalChecksum:4FD159214EB68BC57EB95CF75A590B7B08E80298E189D3EDE82D00E62F8BECF2; UpperCasedChecksum:C8ADDD6DD1CAAC63BF970D6F0BAE45157A387DE75C4BB83734643ED349070AE8; SizeAsReceived:7980; Count:51 x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; x86_64-unknown-linux-gnu) x-tmn: [bDwUoXVqZlF+LTnO12jXgrUhwipqXS8r] x-microsoft-original-message-id: <20200226113157.0f086af6@slackstro.home.lan> x-ms-publictraffictype: Email x-incomingheadercount: 51 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: bfaf1265-f4d0-467b-2c91-08d7baa71c6d x-ms-traffictypediagnostic: DB5EUR03HT161: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: s3B7Ti0hsmuXLYoXQtD/6bcma7du/bPJP14kKGLtYNKWy59JprPOMZFSZoZy2nUDMcP55j80Jc5nlBpLUwrne9ogVor3c+JVw0fG7Xr4LbvZr7XmmPwVX1VDoI1rkTHIGxxiAtMWTpRTG4XflVRtTNTmpVFtTUTUmBRN7Up0i83JssWXKU8prlLufwDxMC5t x-ms-exchange-antispam-messagedata: UHkoqdnnA7St1oTuWwnH0IQhXdD2hvyD7LhsqaV+vVXmI7lUtMhIL+zZ/ieYcpuFEOkRE8ipOgWhoXn4/Qf8WM+af/h1s+GgJ8iL/1e7+2DkmCtk916NIwpxF1DZTY9epYAFTRL5mZXKUM2GtU3ovA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0B7C7464646490458E7AE4A6122E7E5A@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: bfaf1265-f4d0-467b-2c91-08d7baa71c6d X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2020 10:31:59.7984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR03HT161 X-Rspamd-Queue-Id: 48SBtp2dDGz4ZN3 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=hotmail.fr; spf=pass (mx1.freebsd.org: domain of kisscoolandthegangbang@hotmail.fr designates 40.92.71.42 as permitted sender) smtp.mailfrom=kisscoolandthegangbang@hotmail.fr X-Spamd-Result: default: False [-3.80 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; RECEIVED_SPAMHAUS_PBL(0.00)[139.37.1.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.92.0.0/15]; FREEMAIL_FROM(0.00)[hotmail.fr]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(0.00)[ipnet: 40.64.0.0/10(-3.83), asn: 8075(-3.12), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[hotmail.fr,none]; RCVD_IN_DNSWL_NONE(0.00)[42.71.92.40.list.dnswl.org : 127.0.3.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[hotmail.fr]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 26 Feb 2020 10:32:04 -0000 Le Tue, 25 Feb 2020 13:43:50 -0800, Chris a =E9crit : > On Tue, 25 Feb 2020 19:50:11 +0000 kaycee gb > kisscoolandthegangbang@hotmail.fr said > =20 > > Hi, > >=20 > > First, sorry english is not my native language. I will try to be as pre= cise > > as > > possible.=20 > >=20 > > And also I am not sure it is only pf related. Let me know in this case > > please. > > Maybe it would be for net an jail too.=20 > >=20 > > So, I have two cases maybe related.=20 > >=20 > > First one is for using rdr translation rule.=20 > > I have a host with FreeBSD 11.3 amd64 hosting some jails. I want to joi= n > > one service from the outside. Using one rdr rule like this one, all see= ms to > > work fine. I have acces to the service. > > =20 > > > rdr pass on $ext_if inet proto tcp from any to $ext_if port 443 = -> > > > $j_one port 443 =20 > >=20 > > But in case I want to apply some options to this, I have to split it in= 3. > > This > > is the relevant part of my config that makes it work=20 > > =20 > > > # Emulate skip on lo0 > > > pass quick on lo0 from 127.0.0.1 to > > > 127.0.0.1 > > > # jail internal comms > > > pass quick on lo0 from $j_one to $j= _one > > >=20 > > ># other traffic ( do not know yet why it is necessary and why no inter= face > > >specified in mandatory ) > > > pass in quick proto tcp from any to $j_one port 443 > > > > > > # block all on lo0 > > > block log quick on lo0 > > > > > > rdr on $ext_if inet proto tcp from any to $ext_if port 443 -> > > > $j_one port 443 > > > pass in quick on $ext_if proto tcp from any to $j_one port = 443 =20 > >=20 > > See the two lines at the end which are the first two parts. The third p= art > > is > > the line after the "other traffic comment". After a lot of error and re= try, > > this line have to be wrote like that. I can not add "on lo0" on this li= ne or > > the > > service is not reachable.=20 > >=20 > > I'm using jails since some time now and remember having jail traffic bo= und > > to > > lo0 before even in my configuration jails have another interface define= d (a > > bridge generally).=20 > >=20 > > So I would like to know why isn't it possible to limit more this rule ?= I > > tried all other interfaces present in my system, and that do not work > > either. > > Using tcpdump, I can't see the traffic related to this service on any > > interface except the external one. It's a little bit strange for me.=20 > >=20 > > Finally, I will write another mail for the other case. =20 > FWIW I simply add additional lo interfaces (lo0, lo1, lo2, ...) > when I attempt these sort of things. As it seems to simplify things in my > head. > For example, rc.conf > cloned_interfaces=3D"lo1 lo2" > ifconfig_lo1=3D"inet 127.0.0.2" > ifconfig_lo2=3D"inet 127.0.0.3" =20 IIRC, lo1 lo2 ... like bridges bridge0 bridge1 are just "virtual interfaces= " that helps with jail configuration file. Jail traffic is in reality going through lo0.=20 When I started using jails, I was using lo1 lo2 ... too but after trying on= e time or two with bridge interfaces, I decided to stay with bridges, it was = more in my head more like a switch for jails, and that worked in the same way. J= ust a matter of preference.=20 >=20 > This allows me to treat them as any other NIC. I route as necessary to my > NIC to the outside world; pf.conf(5): > EXT_ADDR=3D"ou.ts.ide.ip" > # contains 127.0.0.0/24 and other trusted IPs. Sometimes helpful. > table persist file "/etc/TRUSTED" >=20 >=20 > set skip on { lo0, lo1, lo2 } =20 You could just write set skip on lo0, that would have the same effect. I emulate this for host traffic because I filter inter jails communications. >=20 > # this only represents the rule(s) for lo1 but should be helpful for > # additional rules on lo2 (or more) > nat pass on re0 from { lo1 } to any -> $EXT_ADDR =20 Funny how you write this one. Maybe I'm used to split it in nat and pass as a second rule. IIUC the doc, that's possible to write like this.=20 > rdr pass on re0 proto tcp from any to { lo1 } -> $EXT_ADDR =20 Funny for this one too. I suppose in this case re0 is the external interfac= e. Shouldn't $EXT_ADDR be replaced with jail's address ? Or maybe I'm missing something ?=20 >=20 >=20 > block in > pass out >=20 > =20 With pass in rdr translation rule, like said above that work. My question w= as for when I use rdr translation splited rules.=20 kaycee, P.S. Resent because in first mail forgot pf list From owner-freebsd-pf@freebsd.org Wed Feb 26 15:39:16 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6CB7D25BB52 for ; Wed, 26 Feb 2020 15:39:16 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48SKjG0rLVz44Kf for ; Wed, 26 Feb 2020 15:39:13 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 01QFdLZF012912 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Feb 2020 07:39:28 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: kaycee gb Subject: Re: usage of rdr and pass validation Date: Wed, 26 Feb 2020 07:39:27 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48SKjG0rLVz44Kf X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of bsd-lists@BSDforge.com has no SPF policy when checking 24.113.41.81) smtp.mailfrom=bsd-lists@BSDforge.com X-Spamd-Result: default: False [-1.12 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[bsd-lists@BSDforge.com]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.73)[-0.729,0]; IP_SCORE(-0.30)[ip: (-0.56), ipnet: 24.113.0.0/16(-0.28), asn: 11404(-0.62), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[BSDforge.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[hotmail.fr]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 26 Feb 2020 15:39:16 -0000 On Wed, 26 Feb 2020 10:31:59 +0000 kaycee gb kisscoolandthegangbang@hotmail= =2Efr said > Le Tue, 25 Feb 2020 13:43:50 -0800, > Chris a =C3=A9crit : >=20 > > On Tue, 25 Feb 2020 19:50:11 +0000 kaycee gb > > kisscoolandthegangbang@hotmail=2Efr said > > =20 > > > Hi, > > >=20 > > > First, sorry english is not my native language=2E I will try to be as > > precise > > > as > > > possible=2E=20 > > >=20 > > > And also I am not sure it is only pf related=2E Let me know in this cas= e > > > please=2E > > > Maybe it would be for net an jail too=2E=20 > > >=20 > > > So, I have two cases maybe related=2E=20 > > >=20 > > > First one is for using rdr translation rule=2E=20 > > > I have a host with FreeBSD 11=2E3 amd64 hosting some jails=2E I want to j= oin > > > one service from the outside=2E Using one rdr rule like this one, all s= eems > > to > > > work fine=2E I have acces to the service=2E > > > =20 > > > > rdr pass on $ext_if inet proto tcp from any to $ext_if port 443 = -> > > > > $j_one port 443 =20 > > >=20 > > > But in case I want to apply some options to this, I have to split it = in 3=2E > > > This > > > is the relevant part of my config that makes it work=20 > > > =20 > > > > # Emulate skip on lo0 > > > > pass quick on lo0 from 127=2E0=2E0=2E1 to > > > > 127=2E0=2E0=2E1 > > > > # jail internal comms > > > > pass quick on lo0 from $j_one to > > $j_one > > > >=20 > >> ># other traffic ( do not know yet why it is necessary and why no > >interface > >> >specified in mandatory ) > > > > pass in quick proto tcp from any to $j_one port 4= 43 > > > > > > > > # block all on lo0 > > > > block log quick on lo0 > > > > > > > > rdr on $ext_if inet proto tcp from any to $ext_if port 443 -> > > > > $j_one port 443 > > > > pass in quick on $ext_if proto tcp from any to $j_one por= t 443=20 > >=20 > > >=20 > > > See the two lines at the end which are the first two parts=2E The third= part > > > is > > > the line after the "other traffic comment"=2E After a lot of error and > > retry, > > > this line have to be wrote like that=2E I can not add "on lo0" on this = line > > or > > > the > > > service is not reachable=2E=20 > > >=20 > > > I'm using jails since some time now and remember having jail traffic = bound > > > to > > > lo0 before even in my configuration jails have another interface defi= ned > > (a > > > bridge generally)=2E=20 > > >=20 > > > So I would like to know why isn't it possible to limit more this rule= ? I > > > tried all other interfaces present in my system, and that do not work > > > either=2E > > > Using tcpdump, I can't see the traffic related to this service on any > > > interface except the external one=2E It's a little bit strange for me=2E= =20 > > >=20 > > > Finally, I will write another mail for the other case=2E =20 > > FWIW I simply add additional lo interfaces (lo0, lo1, lo2, =2E=2E=2E) > > when I attempt these sort of things=2E As it seems to simplify things in = my > > head=2E > > For example, rc=2Econf > > cloned_interfaces=3D"lo1 lo2" > > ifconfig_lo1=3D"inet 127=2E0=2E0=2E2" > > ifconfig_lo2=3D"inet 127=2E0=2E0=2E3" =20 >=20 > IIRC, lo1 lo2 =2E=2E=2E like bridges bridge0 bridge1 are just "virtual interfac= es" > that helps with jail configuration file=2E Jail traffic is in reality going > through lo0=2E=20 > When I started using jails, I was using lo1 lo2 =2E=2E=2E too but after trying = one > time or two with bridge interfaces, I decided to stay with bridges, it wa= s > more > in my head more like a switch for jails, and that worked in the same way=2E > Just > a matter of preference=2E Sure=2E Understood=2E :) The server I excerpt these from has a *much* larger pf=2Econf(1), and manages (filters mostly) ~50 million IPs=2E I chose things as they are, because somehow they made it easier in my head at the time=2E :) > >=20 > > This allows me to treat them as any other NIC=2E I route as necessary to = my > > NIC to the outside world; pf=2Econf(5): > > EXT_ADDR=3D"ou=2Ets=2Eide=2Eip" > > # contains 127=2E0=2E0=2E0/24 and other trusted IPs=2E Sometimes helpful=2E > > table persist file "/etc/TRUSTED" > >=20 > >=20 > > set skip on { lo0, lo1, lo2 } =20 >=20 > You could just write set skip on lo0, that would have the same effect=2E I > emulate this for host traffic because I filter inter jails communications= =2E *Actually* it is enough to simply use lo, and in fact I still do=2E But there were some changes to pf(4), (some I think should not have been made) that currently prevent me from using that=2E I had to roll back one of our 12=2Ex servers because of the changes=2E > >=20 > > # this only represents the rule(s) for lo1 but should be helpful for > > # additional rules on lo2 (or more) > > nat pass on re0 from { lo1 } to any -> $EXT_ADDR =20 >=20 > Funny how you write this one=2E Maybe I'm used to split it in nat and pass = as > a second rule=2E IIUC the doc, that's possible to write like this=2E=20 >=20 > > rdr pass on re0 proto tcp from any to { lo1 } -> $EXT_ADDR =20 >=20 > Funny for this one too=2E I suppose in this case re0 is the external > interface=2E > Shouldn't $EXT_ADDR be replaced with jail's address ? Or maybe I'm missin= g > something ? To be honest, I've migrated many of my rules from ~releng8=2E It's what worked at the time, and even tho pf(4) has changed=2E I haven't=2E ;) > >=20 > >=20 > > block in > > pass out > >=20 > > =20 >=20 > With pass in rdr translation rule, like said above that work=2E My question > was > for when I use rdr translation splited rules=2E Sorry=2E I had difficulty fully determining your goal=2E As the rule lines got wrapped in the email messages=2E >=20 > kaycee, >=20 > P=2ES=2E Resent because in first mail forgot pf list NP=2E :) --Chris > _______________________________________________ > freebsd-pf@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd=2Eorg" From owner-freebsd-pf@freebsd.org Thu Feb 27 09:08:53 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B40AD259BF2 for ; Thu, 27 Feb 2020 09:08:53 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from mail.opal.com (tunnel103479-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:113d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.opal.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48Sn0N1l1Dz3R9R for ; Thu, 27 Feb 2020 09:08:51 +0000 (UTC) (envelope-from fbsd@opal.com) Received: from localhost ([IPv6:2001:470:8cb8:4:0:0:0:2]) (authenticated bits=0) by mail.opal.com (8.15.2/8.15.2) with ESMTPSA id 01R98ixe058605 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 27 Feb 2020 04:08:45 -0500 (EST) (envelope-from fbsd@opal.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opal.com; s=mail; t=1582794525; bh=oi/eE7qlSNmXYAGDLMcZrMty/CO522oJJ7SxAUCeIxw=; h=Date:From:To:Subject; b=oxLFmoMRNbof1tw0zBOfR0fd4t6eLVSShZ5ntRFLyhA5/DuhtfUikee0ry0qvv/qs aFFqK0sGS7SiZjUS1bqXq3YFlUFV7O2kui5eJ0hho8KUHwEzqWoVSZ/gnanDfVxXfQ 8AaTueIy0x1Yl4NJgv0eIfmCKhWix2ywksfzuVLs= Date: Thu, 27 Feb 2020 10:08:37 +0100 From: "J.R. Oldroyd" To: freebsd-pf@freebsd.org Subject: Updating our translation functionality Message-ID: <20200227100837.02d60d16@opal.com> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.opal.com [IPv6:2001:470:8cb8:2:0:0:0:1]); Thu, 27 Feb 2020 04:08:45 -0500 (EST) X-Rspamd-Queue-Id: 48Sn0N1l1Dz3R9R X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=opal.com header.s=mail header.b=oxLFmoMR; dmarc=none; spf=pass (mx1.freebsd.org: domain of fbsd@opal.com designates 2001:470:1f06:113d::2 as permitted sender) smtp.mailfrom=fbsd@opal.com X-Spamd-Result: default: False [-4.16 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[opal.com:s=mail]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[opal.com]; DKIM_TRACE(0.00)[opal.com:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.66)[ipnet: 2001:470::/32(-4.65), asn: 6939(-3.58), country: US(-0.05)]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Thu, 27 Feb 2020 09:08:53 -0000 Hi, I read back and found the thread last August "Update to PF from OpenBSD 6.5". I was going to ask the same thing but, given the complexities discussed in the responses there, perhaps the question should be asked a different way round. How much work would it be to add in OpenBSD's latest translation functionality to our implementation? OpenBSD's pf has new translation functionality, specifically nat64 support using the "af-to" syntax. At the same time, existing translation syntax was changed with the nat, binat and rdr rule syntax changing to "pass ... nat-to ..." etc. I think it is good that we are still called "pf" here and that we do try to maintain compatibility with other pf implementations. So, we should consider adding the new translation functionality to our implementation. Understood that this means requiring changes to existing pf.conf configurations but these can be documented with examples and announced in advance. How big of a project would this be? -jr From owner-freebsd-pf@freebsd.org Thu Feb 27 09:21:11 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 805C525A0CE for ; Thu, 27 Feb 2020 09:21:11 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48SnGY6DgKz47xL for ; Thu, 27 Feb 2020 09:21:09 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 90AA612718 for ; Thu, 27 Feb 2020 09:21:08 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [192.168.183.1] (ptr-8rg5e4fkliivy5q45h6.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2408:6002:453c:fdb5:7656:62ba]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 12C70C1CB for ; Thu, 27 Feb 2020 10:21:07 +0100 (CET) From: "Kristof Provost" To: freebsd-pf@freebsd.org Subject: Re: Updating our translation functionality Date: Thu, 27 Feb 2020 10:21:06 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: <966CF6DF-0EFF-4F92-924C-552F4F72A6A0@FreeBSD.org> In-Reply-To: <20200227100837.02d60d16@opal.com> References: <20200227100837.02d60d16@opal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Thu, 27 Feb 2020 09:21:11 -0000 On 27 Feb 2020, at 10:08, J.R. Oldroyd wrote: > I read back and found the thread last August "Update to PF from > OpenBSD > 6.5". > > I was going to ask the same thing but, given the complexities > discussed > in the responses there, perhaps the question should be asked a > different > way round. > > How much work would it be to add in OpenBSD's latest translation > functionality to our implementation? > > OpenBSD's pf has new translation functionality, specifically nat64 > support using the "af-to" syntax. At the same time, existing > translation syntax was changed with the nat, binat and rdr rule > syntax changing to "pass ... nat-to ..." etc. > > I think it is good that we are still called "pf" here and that we do > try > to maintain compatibility with other pf implementations. So, we > should > consider adding the new translation functionality to our > implementation. > Understood that this means requiring changes to existing pf.conf > configurations but these can be documented with examples and announced > in advance. > > How big of a project would this be? > I don’t know. I’ve not specifically investigated the nat64 bits, and they’re (to me) the least interesting bits as well. It’s possible that they can be imported without too much trouble, but someone would have to sit down and spend the time on it. Right now this isn’t even on my todo list and I’m not planning to add it either. Given that this change would break compatibility with existing configurations (unless significant extra work is done to cope with this) I’m not keen on it. I’d need to see very good arguments for introducing an intermediate painful step between the current situation and a state where we have the same syntax as OpenBSD. If you’re looking for nat64, IPFW has an implementation. Best regards, Kristof From owner-freebsd-pf@freebsd.org Thu Feb 27 14:01:29 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DA7A52426FC for ; Thu, 27 Feb 2020 14:01:29 +0000 (UTC) (envelope-from kisscoolandthegangbang@hotmail.fr) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03olkn0825.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::825]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48SvTz6YJwz4KBT for ; Thu, 27 Feb 2020 14:01:27 +0000 (UTC) (envelope-from kisscoolandthegangbang@hotmail.fr) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XvBwB3GWekMaAO+H8gA8VGye6I4eoJkGHsbuIMZCZWbt96YbskGpXfSqPRm9976qE1mqFECOZWsBCbSIbKMnxwwrcXLOs3l40auGD/e05mII5p8HKPUfX7fgzDPEQ2F1XqAOSlB/Pz2ff0IXxjkHh/tsvQi4pU7Bagh9z5nyzutTOAn+Bv4bVHRJew1ylzyz5bxl00ARIHhRdvM6nfK/OJQPuafkt2W1vSClcR+Ep2RAmYIhkdINwQzzu90mRUnLfZvRfOTRLujfbSuJBIf5ukVLv7ANRtCVytPVEE9bvrZD7uCGX6ULtDIGNmkwzCL2DEvr9RISWTgAaiHBCV6kMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+kcEVBFXBcwDaLzqjkZyW0lNE1Mu8bqWGVcy4vkNVxs=; b=HTBPo1zwpztq5x5X7/DtlgSVuh7W0PM5nVE0xSxUyPMh0pyaaWKlsz4mpAC+bwKHxRawhsh5boEPSMQLdn42t10wtgq5ZYL+7lI5D/Z1lwptRCw7gTl4+aaX7gs8lkSPUk73VGV5l1+LnUKiSZ/qK2CSVrzKOXxuNwK5ZMmi7Rji2stVBg4R3TBY3NDn6uttoQD3vXdOcH3bTuRJHN1o87Jhg8yOOm6jDg79zIPwdBDQf/OuNNkYf49NhsZUcuwn7Qw9YN3QzZvIRntl/ykrDEh0FuVM7L5AOaJgUkdITfwXIQ1HlZ7BZ1SiLRecBoe5qllLvrdFINNtlAvpWwh8ig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from DB5EUR03FT013.eop-EUR03.prod.protection.outlook.com (2a01:111:e400:7e0a::34) by DB5EUR03HT093.eop-EUR03.prod.protection.outlook.com (2a01:111:e400:7e0a::442) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Thu, 27 Feb 2020 14:01:21 +0000 Received: from VE1PR03MB5629.eurprd03.prod.outlook.com (10.152.20.55) by DB5EUR03FT013.mail.protection.outlook.com (10.152.20.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Thu, 27 Feb 2020 14:01:21 +0000 Received: from VE1PR03MB5629.eurprd03.prod.outlook.com ([fe80::157c:e8c6:4788:a521]) by VE1PR03MB5629.eurprd03.prod.outlook.com ([fe80::157c:e8c6:4788:a521%7]) with mapi id 15.20.2750.024; Thu, 27 Feb 2020 14:01:21 +0000 Received: from mail.lacabanedeladmin.trickip.net (93.1.37.139) by AM0PR05CA0011.eurprd05.prod.outlook.com (2603:10a6:208:55::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14 via Frontend Transport; Thu, 27 Feb 2020 14:01:20 +0000 Received: from slackstro.home.lan ([172.16.93.12]) (authenticated bits=0) by mail.lacabanedeladmin.trickip.net (8.15.2/8.15.2) with ESMTPSA id 01RE1Ikl087159 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 27 Feb 2020 15:01:18 +0100 (CET) (envelope-from kisscoolandthegangbang@hotmail.fr) From: kaycee gb To: "freebsd-pf@freebsd.org" Subject: Re: usage of rdr and pass validation Thread-Topic: usage of rdr and pass validation Thread-Index: AQHV7BTK93gfeOMNTUCzAPORpfn2zQ== Date: Thu, 27 Feb 2020 14:01:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM0PR05CA0011.eurprd05.prod.outlook.com (2603:10a6:208:55::24) To VE1PR03MB5629.eurprd03.prod.outlook.com (2603:10a6:803:11e::30) x-incomingtopheadermarker: OriginalChecksum:756721186D45744FBA9BE9D561D338A9A6239EB32D59FD137AAE8EA0604CC55D; UpperCasedChecksum:4B5CE0544A0434FB6116A9F7E18547FAD39255AB947BBEA5758D40A3C530D8CB; SizeAsReceived:8009; Count:51 x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; x86_64-unknown-linux-gnu) x-tmn: [6E6dAB8Pg7LQwriesqyvWpp0btxcpsdw] x-microsoft-original-message-id: <20200227150110.4ffe0bc2@slackstro.home.lan> x-ms-publictraffictype: Email x-incomingheadercount: 51 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 4fa64340-2236-49e3-db52-08d7bb8d85b7 x-ms-traffictypediagnostic: DB5EUR03HT093: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +xaJ7Kzs6e0qk01qja1gvMFoEClRITz03CXnBNLqKozacy4gHVWx6MofE98SsGjHWKNfhG3CeyKiLGfpvPdqpynN4iKXq6O+AVJl9HbBrERdmJzJVZ80jJGxR2el5d3jZjxKYT6ZwWO9RThFnLLt8d0fPJCPwhtqVh6G92avBkgDejnUhWjFou2AVNkdkynK x-ms-exchange-antispam-messagedata: DmEU5BBzKG9HIQeKmVcX1nPVnSNauaLL1CNr6PeNDV2qPUvv79YfdWK2TaO787g+Bqko0lLHKNirJfWSgBy++5zYDCIoxwzXCTQ9rU7qE6O6PDGvNUUI8w8jyOzDiykjRBfCPqd3EBQgSR9U8I75OA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: <94882AE90746EC45AB408CC49A530EF4@eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 4fa64340-2236-49e3-db52-08d7bb8d85b7 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 14:01:21.3161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR03HT093 X-Rspamd-Queue-Id: 48SvTz6YJwz4KBT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=hotmail.fr; spf=pass (mx1.freebsd.org: domain of kisscoolandthegangbang@hotmail.fr designates 2a01:111:f400:fe08::825 as permitted sender) smtp.mailfrom=kisscoolandthegangbang@hotmail.fr X-Spamd-Result: default: False [-3.80 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; RECEIVED_SPAMHAUS_PBL(0.00)[139.37.1.93.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; FREEMAIL_FROM(0.00)[hotmail.fr]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(0.00)[ipnet: 2a01:111:f000::/36(-3.98), asn: 8075(-3.12), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[hotmail.fr,none]; RCVD_IN_DNSWL_NONE(0.00)[5.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.8.0.e.f.0.0.4.f.1.1.1.0.1.0.a.2.list.dnswl.org : 127.0.3.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[hotmail.fr]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Thu, 27 Feb 2020 14:01:29 -0000 Le Wed, 26 Feb 2020 07:39:27 -0800, Chris a =E9crit : > On Wed, 26 Feb 2020 10:31:59 +0000 kaycee gb > kisscoolandthegangbang@hotmail.fr said >=20 > > Le Tue, 25 Feb 2020 13:43:50 -0800, > > Chris a =E9crit : > >=20 > > > On Tue, 25 Feb 2020 19:50:11 +0000 kaycee gb > > > kisscoolandthegangbang@hotmail.fr said > > > =20 > > > > Hi, > > > >=20 > > > > First, sorry english is not my native language. I will try to be as > > > precise > > > > as > > > > possible.=20 > > > >=20 > > > > And also I am not sure it is only pf related. Let me know in this c= ase > > > > please. > > > > Maybe it would be for net an jail too.=20 > > > >=20 > > > > So, I have two cases maybe related.=20 > > > >=20 > > > > First one is for using rdr translation rule.=20 > > > > I have a host with FreeBSD 11.3 amd64 hosting some jails. I want to= join > > > > one service from the outside. Using one rdr rule like this one, all > > > > seems > > > to > > > > work fine. I have acces to the service. > > > > =20 > > > > > rdr pass on $ext_if inet proto tcp from any to $ext_if port 443 > > > > > -> $j_one port 443 =20 > > > >=20 > > > > But in case I want to apply some options to this, I have to split i= t in > > > > 3. This > > > > is the relevant part of my config that makes it work=20 > > > > =20 > > > > > # Emulate skip on lo0 > > > > > pass quick on lo0 from 127.0.0.1 t= o > > > > > 127.0.0.1 > > > > > # jail internal comms > > > > > pass quick on lo0 from $j_one t= o > > > $j_one > > > > >=20 > > >> ># other traffic ( do not know yet why it is necessary and why no > > >interface > > >> >specified in mandatory ) > > > > > pass in quick proto tcp from any to $j_one port= 443 > > > > > > > > > > # block all on lo0 > > > > > block log quick on lo0 > > > > > > > > > > rdr on $ext_if inet proto tcp from any to $ext_if port 443 -= > > > > > > $j_one port 443 > > > > > pass in quick on $ext_if proto tcp from any to $j_one p= ort > > > > > 443=20 > > >=20 > > > >=20 > > > > See the two lines at the end which are the first two parts. The thi= rd > > > > part is > > > > the line after the "other traffic comment". After a lot of error an= d > > > retry, > > > > this line have to be wrote like that. I can not add "on lo0" on thi= s > > > > line > > > or > > > > the > > > > service is not reachable.=20 > > > >=20 > > > > I'm using jails since some time now and remember having jail traffi= c > > > > bound to > > > > lo0 before even in my configuration jails have another interface de= fined > > > (a > > > > bridge generally).=20 > > > >=20 > > > > So I would like to know why isn't it possible to limit more this ru= le ? > > > > I tried all other interfaces present in my system, and that do not = work > > > > either. > > > > Using tcpdump, I can't see the traffic related to this service on a= ny > > > > interface except the external one. It's a little bit strange for me= .=20 > > > >=20 > > > > Finally, I will write another mail for the other case. =20 > > > FWIW I simply add additional lo interfaces (lo0, lo1, lo2, ...) > > > when I attempt these sort of things. As it seems to simplify things i= n my > > > head. > > > For example, rc.conf > > > cloned_interfaces=3D"lo1 lo2" > > > ifconfig_lo1=3D"inet 127.0.0.2" > > > ifconfig_lo2=3D"inet 127.0.0.3" =20 > >=20 > > IIRC, lo1 lo2 ... like bridges bridge0 bridge1 are just "virtual interf= aces" > > that helps with jail configuration file. Jail traffic is in reality goi= ng > > through lo0.=20 > > When I started using jails, I was using lo1 lo2 ... too but after tryin= g one > > time or two with bridge interfaces, I decided to stay with bridges, it = was > > more > > in my head more like a switch for jails, and that worked in the same wa= y. > > Just > > a matter of preference. > Sure. Understood. :) The server I excerpt these from has a *much* > larger pf.conf(1), and manages (filters mostly) ~50 million IPs. I > chose things as they are, because somehow they made it easier in my head > at the time. :) 50 million, it start to be something :) > > >=20 > > > This allows me to treat them as any other NIC. I route as necessary t= o my > > > NIC to the outside world; pf.conf(5): > > > EXT_ADDR=3D"ou.ts.ide.ip" > > > # contains 127.0.0.0/24 and other trusted IPs. Sometimes helpful. > > > table persist file "/etc/TRUSTED" > > >=20 > > >=20 > > > set skip on { lo0, lo1, lo2 } =20 > >=20 > > You could just write set skip on lo0, that would have the same effect. = I > > emulate this for host traffic because I filter inter jails communicatio= ns. > *Actually* it is enough to simply use lo, and in fact I still do. But the= re > were some changes to pf(4), (some I think should not have been made) that > currently prevent me from using that. I had to roll back one of our 12.x > servers because of the changes. Yeap, changes sometimes make us do that. :x 12.X seems to have introduced a certain amount of changes. I have some sort= of inernal process for installing my systems. Tried to install a 12.0 some wee= ks ago that way and it failed. Had not investigated yet so I stay with 11.3 fo= r the moment. > > >=20 > > > # this only represents the rule(s) for lo1 but should be helpful for > > > # additional rules on lo2 (or more) > > > nat pass on re0 from { lo1 } to any -> $EXT_ADDR =20 > >=20 > > Funny how you write this one. Maybe I'm used to split it in nat and pas= s as > > a second rule. IIUC the doc, that's possible to write like this.=20 > >=20 > > > rdr pass on re0 proto tcp from any to { lo1 } -> $EXT_ADDR =20 > >=20 > > Funny for this one too. I suppose in this case re0 is the external > > interface. > > Shouldn't $EXT_ADDR be replaced with jail's address ? Or maybe I'm miss= ing > > something ? >=20 > To be honest, I've migrated many of my rules from ~releng8. It's what > worked at the time, and even tho pf(4) has changed. I haven't. ;) Maybe you should. At least investigate. 8 to 11 (???) is a long time > > >=20 > > >=20 > > > block in > > > pass out > > >=20 > > > =20 > >=20 > > With pass in rdr translation rule, like said above that work. My questi= on > > was > > for when I use rdr translation splited rules. > Sorry. I had difficulty fully determining your goal. As the rule lines > got wrapped in the email messages. 80 characters long lines is not enough when you have to paste configuration= s space or tab aligned ^^ > # Emulate skip on lo0 > pass quick on lo0 from 127.0.0.1 to 127.0.0.1 > # jail internal comms > pass quick on lo0 from $j_one to $j_one ># other traffic ( do not know yet why it is necessary and why no interface >specified in mandatory ) > pass in quick proto tcp from any to $j_one port 443 > > # block all on lo0 > block log quick on lo0 > > rdr on $ext_if inet proto tcp from any to $ext_if port 443 -> $j_one port= 443 > pass in quick on $ext_if proto tcp from any to $j_one port 443 With that conf I had hard time to understand why I need the "other traffic" rule and why I could not specify an interface with the "on" clause to allow the traffic pass.=20 With deeper debugging, I found that I had this in my pf.conf > private_nets =3D "127/8, 10/8, 100.64/10, 172.16/12, 192/24, 192.168/16, > 169.254/16" > bcast_nets =3D "224.0.0.0/4, 255.255.255.255/32" > table { $private_nets, $bcast_nets, $ext_if:broadcast } >=20 > block in quick on $ext_if to After splitting that to > private_nets =3D "127/8, 10/8, 100.64/10, 172.16/12, 192/24, 192.168/16, > 169.254/16" > bcast_nets =3D "224.0.0.0/4, 255.255.255.255/32" > table { $private_nets } > table { $bcast_nets, $ext_if:broadcast } >=20 > block in quick on $ext_if from > block in quick on $ext_if to I have the configuration I was expecting and it's working. I wonder now why blocking internal nets inbound on external if was reacting like that. I remember reading something about how pf do rdr operations. I have to confir= m this but for the moment it's ok. =20 =20 It also solved my second case ^^ Thanks, kaycee, From owner-freebsd-pf@freebsd.org Fri Feb 28 23:35:41 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 98643248D4F for ; Fri, 28 Feb 2020 23:35:41 +0000 (UTC) (envelope-from sean.yeh117@gmail.com) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48TmB31tTfz4NWJ for ; Fri, 28 Feb 2020 23:35:39 +0000 (UTC) (envelope-from sean.yeh117@gmail.com) Received: by mail-pf1-x444.google.com with SMTP id i19so2493537pfa.2 for ; Fri, 28 Feb 2020 15:35:38 -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=meJ8Zh+ryUV0NniIxKdL448UqOwqYacyE6MIaFLBgjg=; b=ZU++6Ep7LV/byv/8IH2NGHp3LdVj6p6VcA3HH14Y2xVbzjtkIOOguXCIJ9IOkV2lZF d9+9aZkZPNgW8pPv7gIp8gp8pOPapjPjR6T5rLgNHlfTjkd0Sc5aeWmS9jrwju2e+W14 tqszpL0d/OV8pqk/fU3cEI1QyBXx4PZ7uWV5ijCx2rGbACmIZD5NQ7tyImO8pSJJpHqI 3vKUs/J05jxtyrqn+grIqDStozCVjIpYN4Aj6Jy2dLnty9GiqwfLp/cj0FMUTU2/jyjd uxR1hMAnQu50gQNZg+rF0P7QXOHZRpcmmArnKt3GxlKgg87WSXZsKYf/BbMG0k4yEgqV roGw== 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=meJ8Zh+ryUV0NniIxKdL448UqOwqYacyE6MIaFLBgjg=; b=rGeJmL4JKgMfpD4myZhod7Gd/lh+KZSxJMiBNdZQSmEMQ0bNmUHhmi4VpMl9GDIoCi HZSHEUG2kVDUSFUoleLDuW8J5klA5JjIrDr6jLuHvnv6jvcojoHdBI8lzvGCv/MPS+oq SHD6gD4xbThOy9Tm8/qze1uP/agQcUy/7sQ5h1rgrOAjJDe7cWa6rqF2vY2iW/FcPBPN Bz1MT2SogDVM+9pvxnAwfeWBBbMpnBreWm2xDfncarT8KBE+jpYPxIRNLHRTSNml6z2i 2ZRBcY5fGotpssxRyBxTZLCasvF/hBjNyHGwoGKb62y75GAAYb+OZKw8sjH7pKqcZlKA Ybaw== X-Gm-Message-State: APjAAAVlE38AwunVIuq5Oo2DrpjWBHma1YGMFZ0piHVdA9kIuzNAXkUQ JD3GB+iPt8Ch9dq0M4PziJvGMgN/grAfqcxkhysXjG2QPIo= X-Google-Smtp-Source: APXvYqzX6J80+xfJXdolJFrl+t5+09b/XTrNCjReznAqG2e+9K6bdkueLn6ZFS2RgHSG++cqx0tcOwBY0YW0ZxZ6nso= X-Received: by 2002:a62:17c4:: with SMTP id 187mr6997946pfx.9.1582932936703; Fri, 28 Feb 2020 15:35:36 -0800 (PST) MIME-Version: 1.0 From: Sean Yeh Date: Fri, 28 Feb 2020 15:35:23 -0800 Message-ID: Subject: ALTQ feature of PF in FreeBSD To: freebsd-pf@freebsd.org X-Rspamd-Queue-Id: 48TmB31tTfz4NWJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ZU++6Ep7; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of seanyeh117@gmail.com designates 2607:f8b0:4864:20::444 as permitted sender) smtp.mailfrom=seanyeh117@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; URI_COUNT_ODD(1.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-0.51), ipnet: 2607:f8b0::/32(-1.88), asn: 15169(-1.67), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[4.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 28 Feb 2020 23:35:41 -0000 Hi FreeBSD-pf members, I hope you guys are enjoying your weekend! I was wondering if any of you happened to know if the code for the ALTQ feature of pf could be separated and used for NetBSD's pf function. I'm currently investigating methods to improve NetBSD's ALTQ feature, which hasn't been updated in 15+ years: https://wiki.netbsd.org/projects/project/altq/ According to the man pages of freeBSD's pf function, FreeBSD uses a modified pf of openBSD 4.5 pf function. Are there any complications that you foresee trying to port FreeBSD's current ALTQ code into NetBSD? Thank you for all your help, Sean From owner-freebsd-pf@freebsd.org Sat Feb 29 04:37:25 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B85B1255114 for ; Sat, 29 Feb 2020 04:37:25 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48TttD4NCKz41ft for ; Sat, 29 Feb 2020 04:37:23 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 01T4bX6c049180 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 28 Feb 2020 20:37:39 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: Sean Yeh Subject: Re: ALTQ feature of PF in FreeBSD Date: Fri, 28 Feb 2020 20:37:39 -0800 Message-Id: <1bb2143ad2233dcd646ed1b25a780928@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48TttD4NCKz41ft X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of bsd-lists@BSDforge.com has no SPF policy when checking 24.113.41.81) smtp.mailfrom=bsd-lists@BSDforge.com X-Spamd-Result: default: False [-1.05 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[bsd-lists@BSDforge.com]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.67)[-0.667,0]; IP_SCORE(-0.29)[ip: (-0.54), ipnet: 24.113.0.0/16(-0.27), asn: 11404(-0.61), country: US(-0.05)]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[BSDforge.com]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.995,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 29 Feb 2020 04:37:25 -0000 On Fri, 28 Feb 2020 15:35:23 -0800 Sean Yeh sean=2Eyeh117@gmail=2Ecom said > Hi FreeBSD-pf members, >=20 > I hope you guys are enjoying your weekend! >=20 > I was wondering if any of you happened to know if the code for the ALTQ > feature of pf could be separated and used for NetBSD's pf function=2E I'm > currently investigating methods to improve NetBSD's ALTQ feature, which > hasn't been updated in 15+ years: > https://wiki=2Enetbsd=2Eorg/projects/project/altq/ >=20 > According to the man pages of freeBSD's pf function, FreeBSD uses a > modified pf of openBSD 4=2E5 pf function=2E Are there any complications that > you foresee trying to port FreeBSD's current ALTQ code into NetBSD? In all honesty=2E If you have to ask=2E You will likely find it challenging=2E ;)= ;) But *please* don't let that discourage you! If you're a kernel hacker, and or have a good eye for patterns=2E You should be able to find the similarities by different names to match them up=2E But that doesn't mean that in the end it'll work=2E I haven't personally made any comparisons=2E I'm only familiar with the FreeBSD variety=2E My 2=C2=A2 FWIW :) --Chris FreeBSD 14=2E0-FUTURE #0=2E000 cray256 >=20 > Thank you for all your help, >=20 > Sean > _______________________________________________ > freebsd-pf@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd=2Eorg" From owner-freebsd-pf@freebsd.org Sat Feb 29 13:28:00 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5CB2325F4EB for ; Sat, 29 Feb 2020 13:28:00 +0000 (UTC) (envelope-from sean.yeh117@gmail.com) Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48V6fN4C8Fz4fFf for ; Sat, 29 Feb 2020 13:27:56 +0000 (UTC) (envelope-from sean.yeh117@gmail.com) Received: by mail-pf1-x441.google.com with SMTP id l184so607977pfl.7 for ; Sat, 29 Feb 2020 05:27:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=iyPUOM0+CEZ9j/58N7hChvrhR1sN1RuBds1dO8mdMX8=; b=DYE8FSahKQHXUyBVTBQsarUBpYcSDC/qs8ZnxsSnFnMWCt+3sN/k37PrYdX48Xb8yN O3lAQPPASukYvoZTa4yhoattaWM4OZZF0YWXSO/AqmhKcC8viu+6Flu9eINma6xQEZw2 rWyc16Y3XbqaThkXHOK7SAEtbClpJNBWr0mMLBSpjWxl/4M6pkyMidqCLeRbW48bxe6D F7IY389PUsGdW+g+tcMtDu47dQwDx6oOVFxh4NiS939/N33SrbkFfwHSoQEaJMwI6c/w 3hdQL63VSak+ERTnaRq1o/38IwaTRot49CbplM8G0+V6JwEdXqIP9Mzom0IzqNYeuxU1 +R7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iyPUOM0+CEZ9j/58N7hChvrhR1sN1RuBds1dO8mdMX8=; b=tf9bMx9ZBk1oVVGnnPWDdlnvbiI7HacbjJnM44GQ0fWc+2ey7BYgS5mYuO0fy+/A6h yBurzoStW4WtHcyc8trmShkmHtLSxw0kxmqyTE3bfZMg9PDcb21sDOgFVZsKni6WorAB eA43AGYbEWfVqNHSL3q3eArIxcn3oz4b7v3gVuMz8lWQfNpknvatwYQCc5FjJfvokAfu PeKu2M0uXvEh9LSZIhcv45NTnPWS+pg4CHPP5qPhy/KE6e9bdP3thUYQ9kYw6bV+ATCx Q4AiaJMs7YquEWa49bZhlj+/gQQXtV2cdY1Z5SzUDuspSIi3r+5HudP7O9rzD/Iw8Teo RNDw== X-Gm-Message-State: APjAAAXBPeVjQAT+MCa65ykox+1bn+igiyalukpVW4kEuAYr1D8nZr0+ XhViB7FlN1DofCuc0L7KnGk8Ba/HA6VfLqkq2pqPqvoh X-Google-Smtp-Source: APXvYqwmcmG9KEYEPVZTEiL1dhsTiWqKgMhfG8tXtdY1I4N+6HSuTn4PMvGWeYwQjTESU2Of5QbI8SlxHEeG4pKq+7U= X-Received: by 2002:a63:4282:: with SMTP id p124mr10140249pga.59.1582982874561; Sat, 29 Feb 2020 05:27:54 -0800 (PST) MIME-Version: 1.0 References: <1bb2143ad2233dcd646ed1b25a780928@udns.ultimatedns.net> In-Reply-To: <1bb2143ad2233dcd646ed1b25a780928@udns.ultimatedns.net> From: Sean Yeh Date: Sat, 29 Feb 2020 05:27:42 -0800 Message-ID: Subject: Re: ALTQ feature of PF in FreeBSD To: bsd-lists@bsdforge.com, freebsd-pf@freebsd.org X-Rspamd-Queue-Id: 48V6fN4C8Fz4fFf X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=DYE8FSah; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of seanyeh117@gmail.com designates 2607:f8b0:4864:20::441 as permitted sender) smtp.mailfrom=seanyeh117@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.4.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; IP_SCORE(0.00)[ip: (-0.58), ipnet: 2607:f8b0::/32(-1.88), asn: 15169(-1.67), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 29 Feb 2020 13:28:00 -0000 Hi Chris (and FreeBSD-pf members), Thanks for the advice! Truth be told, I am quite lost right now. But before I give up, could you please point me in the right direction? 1) Figuring out if ALTQ is separable from pf is a little abstract to me. Is there a definitive experiment to perform to answer this question? Currently, I'm just looking and taking note of the differences between NetBSD's and FreeBSD's pf/altq code. What other steps should I be taking? 2) What are some indications that a port will fail/work? When I find a difference between NetBSD's and FreeBSD's code, I've already discovered several, what questions should I ask myself to determine whether or not the difference will be an issue or not. I'm sorry if these questions seem trivial or basic. I am truly appreciative of all your time and help. Best, Sean On Fri, Feb 28, 2020 at 8:37 PM Chris wrote: > On Fri, 28 Feb 2020 15:35:23 -0800 Sean Yeh sean.yeh117@gmail.com said > > > Hi FreeBSD-pf members, > > > > I hope you guys are enjoying your weekend! > > > > I was wondering if any of you happened to know if the code for the ALTQ > > feature of pf could be separated and used for NetBSD's pf function. I'm > > currently investigating methods to improve NetBSD's ALTQ feature, which > > hasn't been updated in 15+ years: > > https://wiki.netbsd.org/projects/project/altq/ > > > > According to the man pages of freeBSD's pf function, FreeBSD uses a > > modified pf of openBSD 4.5 pf function. Are there any complications tha= t > > you foresee trying to port FreeBSD's current ALTQ code into NetBSD? > In all honesty. If you have to ask. You will likely find it challenging. > ;) ;) > But *please* don't let that discourage you! > If you're a kernel hacker, and or have a good eye for patterns. You shoul= d > be able to find the similarities by different names to match them up. > But that doesn't mean that in the end it'll work. I haven't personally > made any comparisons. I'm only familiar with the FreeBSD variety. > > My 2=C2=A2 FWIW :) > > --Chris > FreeBSD 14.0-FUTURE #0.000 cray256 > > > > > Thank you for all your help, > > > > Sean > > _______________________________________________ > > 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" > > > From owner-freebsd-pf@freebsd.org Sat Feb 29 20:10:35 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0EFC62672D2 for ; Sat, 29 Feb 2020 20:10:35 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48VHZx2zpwz4cJQ for ; Sat, 29 Feb 2020 20:10:33 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 01TKAndQ068470 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 29 Feb 2020 12:10:55 -0800 (PST) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: Sean Yeh Subject: Re: ALTQ feature of PF in FreeBSD Date: Sat, 29 Feb 2020 12:10:55 -0800 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48VHZx2zpwz4cJQ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of bsd-lists@BSDforge.com has no SPF policy when checking 24.113.41.81) smtp.mailfrom=bsd-lists@BSDforge.com X-Spamd-Result: default: False [-1.07 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[bsd-lists@BSDforge.com]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.70)[-0.700,0]; IP_SCORE(-0.29)[ip: (-0.53), ipnet: 24.113.0.0/16(-0.26), asn: 11404(-0.60), country: US(-0.05)]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[BSDforge.com]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.995,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 29 Feb 2020 20:10:35 -0000 On Sat, 29 Feb 2020 05:27:42 -0800 Sean Yeh sean=2Eyeh117@gmail=2Ecom said >=20 > On Fri, Feb 28, 2020 at 8:37 PM Chris wrote: >=20 > > On Fri, 28 Feb 2020 15:35:23 -0800 Sean Yeh sean=2Eyeh117@gmail=2Ecom said > > > > > Hi FreeBSD-pf members, > > > > > > I hope you guys are enjoying your weekend! > > > > > > I was wondering if any of you happened to know if the code for the AL= TQ > > > feature of pf could be separated and used for NetBSD's pf function=2E I= 'm > > > currently investigating methods to improve NetBSD's ALTQ feature, whi= ch > > > hasn't been updated in 15+ years: > > > https://wiki=2Enetbsd=2Eorg/projects/project/altq/ > > > > > > According to the man pages of freeBSD's pf function, FreeBSD uses a > > > modified pf of openBSD 4=2E5 pf function=2E Are there any complications t= hat > > > you foresee trying to port FreeBSD's current ALTQ code into NetBSD? > > In all honesty=2E If you have to ask=2E You will likely find it challenging= =2E > > ;) ;) > > But *please* don't let that discourage you! > > If you're a kernel hacker, and or have a good eye for patterns=2E You sho= uld > > be able to find the similarities by different names to match them up=2E > > But that doesn't mean that in the end it'll work=2E I haven't personally > > made any comparisons=2E I'm only familiar with the FreeBSD variety=2E > > > > My 2=C2=A2 FWIW :) > > > > --Chris > > FreeBSD 14=2E0-FUTURE #0=2E000 cray256 > > > > > > > > Thank you for all your help, > > > > > > Sean > -------------------------------------------------- > reflowed for context=2E Because top posting is evil > -------------------------------------------------- >=20 > Hi Chris (and FreeBSD-pf members), >=20 > Thanks for the advice! >=20 > Truth be told, I am quite lost right now=2E But before I give up, could you > please point me in the right direction? >=20 > 1) Figuring out if ALTQ is separable from pf is a little abstract to me=2E > Is there a definitive experiment to perform to answer this question? > Currently, I'm just looking and taking note of the differences between > NetBSD's and FreeBSD's pf/altq code=2E What other steps should I be > taking? First off, let me state=2E That you're intentions are admirable, and what follows is not intended to be denigrating in any way=2E That said; my first statement still holds=2E Many have wanted to take on and make improvements, and changes to the pf(4), and altq(4) source -- more so to pf=2E But quickly discovered the sheer complexity of the routines, and algos of the source=2E I could liken them to crypto routines=2E Many of these were seasoned programmers/hackers=2E So the code is brittle, and resistant to change except to those well familiar=2E If you're the tenacious type, like myself=2E I would say your first step needs to become well familiar with the source=2E Immerse yourself in it=2E You'll quickly discover that you need to become familiar with the kernel source, as well=2E Oh, and you're a net guru=2E Right? ;) I'm serious=2E That's what it's going to take, to have any meaningful conversation regarding the changes you propose -- and I'm happy to have them with you=2E If you want to proceed=2E :) If I haven't scared you off=2E I'll look forward to hearing from you=2E :) --Chris >=20 > 2) What are some indications that a port will fail/work? > When I find a difference between NetBSD's and FreeBSD's code, > I've already discovered several, what questions should I ask myself > to determine whether or not the difference will be an issue or not=2E >=20 > I'm sorry if these questions seem trivial or basic=2E I am truly > appreciative of all your time and help=2E >=20 > Best, >=20 > Sean