From owner-freebsd-net@freebsd.org Mon Jan 6 15:46:45 2020 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 BFF481ED8D9 for ; Mon, 6 Jan 2020 15:46:45 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47s0HS6Hg7z3NhT for ; Mon, 6 Jan 2020 15:46:44 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 006FkQSq057522 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jan 2020 15:46:29 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: danielmorandini@me.com Received: from [10.58.0.4] (dadv@[10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 006FkKnj055778 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Jan 2020 22:46:20 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: lagg interface To: Daniel Morandini , freebsd-net@freebsd.org References: <19FC0FD7-A2C4-442A-BCB2-0CF8D0726EA1@me.com> From: Eugene Grosbein Message-ID: Date: Mon, 6 Jan 2020 22:46:17 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <19FC0FD7-A2C4-442A-BCB2-0CF8D0726EA1@me.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 47s0HS6Hg7z3NhT X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.83 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-1.73)[ip: (-4.70), ipnet: 2a01:4f8::/29(-2.44), asn: 24940(-1.51), country: DE(-0.02)]; FREEMAIL_TO(0.00)[me.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(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: Mon, 06 Jan 2020 15:46:45 -0000 06.01.2020 17:56, Daniel Morandini via freebsd-net wrote: > Dear FreeBSD community, > I am building a prototype router which provides a network access point to its client through a wireless interface > (rtwn0: Realtek 802.11n WLAN Adapter, class 0/0, rev 2.00/2.00, addr 4). > Currently the packets received from the wlan0 interface are NATed through my phone attached via usb cable, > tethering mode enabled (ipheth1: ). > > What I would to do is to improve the network throughput by exploiting two phones instead of one. > For that I was testing the lagg(4) interface, but I have troubles debugging why the link does not get up > (I never managed to have at least a laggport ). > >>From what I got from the docs, I cannot expect to be able to use “ acp” as distribution algo, > as it requires the other side of the links (the phones in this case), to implement the proto too, Correct. > and it is not the case. I would expect to see “failover”, “loadbalance” and “roundrobin” to work though. Lagg cannot be used in your case at all, because lagg deals with traffic at layer2 but your setup involves NAT (layer3) that prevents usage of lagg. Also, you better distribute traffic so that all traffic of same client (internal IP) is translated to same external IP address or else clients could have difficulties with some internet services (sites). At very least, traffic from single client to distinct service must be translated to same external IP address. So, you need L3 traffic sharing. One example is using ipfw tables. For N external links (phones) you'd need (N-1) tables, one table for a link excluding first one. With two links, you need only one table listing clients using second link: lan="10.0.0.0/8,192.168.0.0/16" ipfw disable one_pass ipfw table 1 add 10.0.10.200 # a client using second link ipfw table 1 add 192.168.0.5 # another client for second link # translate incoming traffic ipfw delete 50 ipfw add 50 nat 123 ip from any to any in recv ipheth0 ipfw add 50 nat 123 ip from any to any in recv ipheth1 # insert your filtering rules between 50 and 50000 # translate and forward outgoing traffic # clients of second link processed later with rules 50110 etc. ipfw add 50000 skipto 50110 ip from not 'table(1)' to not $lan out # other clients not mentioned in the table are NAT-ed and forwarded here ipfw add 50010 nat 123 ip from $lan to not $lan out ipfw add 50020 fwd $gw1 ip from $nat123_extip to any out # clients using second link are NAT-ed and forwarded here ipfw add 50110 nat 124 ip from $lan to not $lan out ipfw add 50120 fwd $gw2 ip from $nat124_extip to any out