From owner-freebsd-net@freebsd.org Mon Feb 1 12:26:33 2021 Return-Path: Delivered-To: freebsd-net@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 156E64FD9E1 for ; Mon, 1 Feb 2021 12:26:33 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4DTnHX0p1pz3Cp2 for ; Mon, 1 Feb 2021 12:26:31 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: by mail-ej1-x631.google.com with SMTP id r12so24026076ejb.9 for ; Mon, 01 Feb 2021 04:26:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxpowered-net.20150623.gappssmtp.com; s=20150623; h=to:references:from:subject:message-id:date:user-agent:mime-version :in-reply-to; bh=HHopF0T5TGC7iy5AG11VC6zPOTmAZq5nXLS+szKeQnY=; b=VKeX6Wo/jPgLp8ygq00hdOwA1oGrjLgK/FzZH04cA+wL8wSMh5yN266xy8RdaUaT3r 5SP7bjjS0AKaPHEmnHMUGUdEMiAEyT67gzG7HQm0AAmga1X6zzayAtQVwVHx8RNfyIgt AlWubd/VKV09//0NNgTZ9Q7UXa8ZnZaYiSrkJawTJLINsr2sF7BfJCw7nqJFIQwkmtsq beUcnXbiZgnyOhARVbnmIriKMc0f3OB51AjArd+6ge9Vet3jt3bdn6yUWoAjof+STBOF b6srBUnG+sNkk6j2P8CBHEALncJqqybJT/kEeHH1C9daGFtNljUKmRA1oFbR1b9Gw/q2 bXsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:message-id:date :user-agent:mime-version:in-reply-to; bh=HHopF0T5TGC7iy5AG11VC6zPOTmAZq5nXLS+szKeQnY=; b=tH6YFxyfCHKPQ3a83LkGFcZIZbhaEyuWkCashMr3NyBwM8RxT0mDFJEL0WZ6FvEIyJ VtxAk+wYEuAb+Mha5/O01qg3b956H6wuVKfV/cOAkHy07zPh/sWWRBci9DcoFal7nbwX E7FPbciutX6+JQIt7yQ4j5RW27fAKxUVwb8/cpAwCvRKBCcO61hExpJl65hsiaYAX7tk cKPsG5jAiEwdyRNndwii18Y6B6tU1OaqCTSnXDiPSNymdb/kMUOl1lqZKnK2WNWmAZ2I FAo+hFh27M+AC8iM0KjJRS4ujcPLIfjh5R99pTZXiYb2hSGyz6ayytH0Bcd4tZ+Zvdzl 19LQ== X-Gm-Message-State: AOAM531+OJw+vIsXsZll8eaj7/St2wDDt6N938JDGWl8pVoxp0gfGMya ovvPpILyJ2o4LiN43UTQk+OzOcfxL2ESfA== X-Google-Smtp-Source: ABdhPJzLbkOWDJHXVSPnoWMw8zOI6mE3+V/2N13WfCvyYn/qI0xFuLXXHlDQ3I6U9L8W+C0QeGVBbA== X-Received: by 2002:a17:906:57d4:: with SMTP id u20mr1313580ejr.247.1612182390127; Mon, 01 Feb 2021 04:26:30 -0800 (PST) Received: from proton.tuxpowered.net ([2a04:4540:6a17:ad00:ecc9:4b5c:1cfd:a738]) by smtp.gmail.com with ESMTPSA id g14sm8615722edm.31.2021.02.01.04.26.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Feb 2021 04:26:29 -0800 (PST) To: Eugene Grosbein , freebsd-net@FreeBSD.org References: <14fc5e0a-7d36-e040-f87c-48cf54490b7b@grosbein.net> From: Kajetan Staszkiewicz Subject: Re: How to not send traffic to TCP/IP stack Message-ID: <2abf8b29-41c3-6a98-fde6-24b33fe3ccfd@tuxpowered.net> Date: Mon, 1 Feb 2021 13:26:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <14fc5e0a-7d36-e040-f87c-48cf54490b7b@grosbein.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="muG0wZl4cI4HMkA7p8Vc1edf4mhPwZ81x" X-Rspamd-Queue-Id: 4DTnHX0p1pz3Cp2 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tuxpowered-net.20150623.gappssmtp.com header.s=20150623 header.b=VKeX6Wo/; dmarc=none; spf=pass (mx1.freebsd.org: domain of vegeta@tuxpowered.net designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=vegeta@tuxpowered.net X-Spamd-Result: default: False [-5.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[tuxpowered-net.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::631:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[tuxpowered-net.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[tuxpowered.net]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::631:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::631:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2021 12:26:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --muG0wZl4cI4HMkA7p8Vc1edf4mhPwZ81x Content-Type: multipart/mixed; boundary="jl6Rptj1MYcPNx1Py4puuIRp8PelDXknu"; protected-headers="v1" From: Kajetan Staszkiewicz To: Eugene Grosbein , freebsd-net@FreeBSD.org Message-ID: <2abf8b29-41c3-6a98-fde6-24b33fe3ccfd@tuxpowered.net> Subject: Re: How to not send traffic to TCP/IP stack References: <14fc5e0a-7d36-e040-f87c-48cf54490b7b@grosbein.net> In-Reply-To: <14fc5e0a-7d36-e040-f87c-48cf54490b7b@grosbein.net> --jl6Rptj1MYcPNx1Py4puuIRp8PelDXknu Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 29.01.21 19:45, Eugene Grosbein wrote: > 29.01.2021 22:15, Kajetan Staszkiewicz wrote: >=20 >> So far so good. But what if a LB wants to access the service? >> >> SYN: >> 1. LB sends out a packet through public interface becuase that's where= >> the default gateway points. >> 2. Core router sends the packet to one of LBs, in this case the same o= ne >> who originated the packet. >> 3. It arrives at the public interface of LB where it is matched again= st >> a route-to pf rule. A public-side pf state is created, a tag is assign= ed. >> 4. pf's rout-to routes it to a LB Node / target. >> 5. Leaves the LB over internal interface, matches the tag, another sta= te >> is created. >> >> ACK: >> 1. From LB Node >> 2. Hits internal interface of LB, the state is already there. >> 3. Normal routing decision of LB decides to send the packet to IP stac= k. >> 4. The packet never hits the pf state on the public side of LB. >> 5. The public side pf state never sees ACK from the LB Node, the state= >> times out very fast. >> >> My goal is to have loadbalanced connections to *always* behave like th= ey >> come from the Internet, that is to leave the LB and bounce off the cor= e >> router. >=20 > I'm not a pf user, so I wonder: why do you need to create any firewall = state > for such traffic at all? Can't you route such packets in stateless mode= ? > I don't see any value in pf states for such packets. Which ones? There is a total of 3 pf states created here, 2 on public side (outgoing, incoming-LB), 1 on internal (post-LB). That would still not allow me to avoid sending packets to the IP stack, would it? The only way I've found to force outgoing interface while skipping routing is via "reply-to" target of pf, but that requires static gateway in pf rules, which is not an option for me because gateway is installed from BGP. --=20 | pozdrawiam / greetings | Powered by macOS, Debian and FreeBSD | | Kajetan Staszkiewicz | www: http://vegeta.tuxpowered.net | `------------------------^--------------------------------------' --jl6Rptj1MYcPNx1Py4puuIRp8PelDXknu-- --muG0wZl4cI4HMkA7p8Vc1edf4mhPwZ81x Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wmMEABEIACMWIQSOEQZObv2B8mf0JbnjtFCvbXs6FAUCYBfzdAUDAAAAAAAKCRDjtFCvbXs6FDwC AKCvlIy6lleWraAKqVn3PuzjPrCFpACg5FsOVOagi86Nm1PHLOLgktxjwEA= =36HQ -----END PGP SIGNATURE----- --muG0wZl4cI4HMkA7p8Vc1edf4mhPwZ81x--