From owner-freebsd-net@freebsd.org Wed Oct 9 18:41:51 2019 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 2BCB712B3A3 for ; Wed, 9 Oct 2019 18:41:51 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (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 46pNNY54Zlz3KlR for ; Wed, 9 Oct 2019 18:41:49 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.15.2/8.15.2) with ESMTP id x99IflbI060929; Wed, 9 Oct 2019 13:41:47 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.16.32.30] (65-36-5-114.static.grandenetworks.net [65.36.5.114]) by mail.shrew.net (Postfix) with ESMTPSA id 80BC41966BB; Wed, 9 Oct 2019 13:41:42 -0500 (CDT) Subject: Re: CARP and NAT question To: Julien Cigar Cc: freebsd-net@freebsd.org References: <20191008134851.GP2691@home.lan> <20191008155813.GS2691@home.lan> <20191009091026.GT2691@home.lan> From: Matthew Grooms Message-ID: Date: Wed, 9 Oct 2019 13:41:40 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191009091026.GT2691@home.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx2.shrew.net [10.24.10.11]); Wed, 09 Oct 2019 13:41:48 -0500 (CDT) X-Rspamd-Queue-Id: 46pNNY54Zlz3KlR X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.132 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [2.05 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RECEIVED_SPAMHAUS_XBL(5.00)[114.5.36.65.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.4]; NEURAL_HAM_MEDIUM(-0.99)[-0.994,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(0.00)[+mx]; NEURAL_HAM_LONG(-0.95)[-0.947,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[shrew.net]; BAD_REP_POLICIES(0.10)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[132.5.97.38.list.dnswl.org : 127.0.10.0]; IP_SCORE(-1.01)[ip: (-9.43), ipnet: 38.0.0.0/8(2.83), asn: 174(1.58), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2019 18:41:51 -0000 On 10/9/2019 4:10 AM, Julien Cigar wrote: > On Tue, Oct 08, 2019 at 11:22:51AM -0500, Matthew Grooms wrote: >> On 10/8/2019 10:58 AM, Julien Cigar wrote: >>> On Tue, Oct 08, 2019 at 10:20:34AM -0500, Matthew Grooms wrote: >>>> Hi Julien, >>> Hi Matthew, >>> >>>> It's not clear why you are trying to assign multiple carp IP address to >>>> two different interfaces from within the same IP subnet. Are you trying >>>> to fail over a 2nd carp address or are you trying to improve >>>> throughput/redundancy? If you just want to fail over a 2nd carp address, >>>> assign a 2nd alias to your first interface. If your trying to improve >>>> throughput/redundancy, assign both interfaces to a lagg and build your >>>> carp interfaces on top of that instead. >>>> >>> Currently outbound traffic from $net1 and $net2 (two private networks) >>> pass through the same network interface (igb0) (as you can see in (1) >>> in my previous post) on the router. I'd like to prevent that >>> $net2 saturates the interface and slow down traffic from $net1 (which is >>> more important). I could lagg and build CARP on top of that but it >>> wouldn't prevent $net2 to saturate the interface (unless I'm plugin ALTQ >>> of course, which I'd like to avoid). >> Well, I'm not sure how well it will work but I think what you are >> looking for is the route-to pf rule option. You can specify that certain >> traffic be transmitted via a specific network interface to a specific >> next hop. However, I believe you'll need to match traffic as it's >> received on the internal interface, ie. before the kernel determines the >> egress interface. >> >> table internal_networks { $net1, $net2 } >> pass in on $internal_interface route-to( igb0 $default_gw ) from $net1 >> to ! >> pass in on $internal_interface route-to( igb1 $default_gw ) from $net2 >> to ! > Thanks, I haven't used the route-to yet but if I understand well it's > a way to "bypass" the default route/interface? Yes. It's essentially pf's way of providing policy based routing in the rule set. -Matthew