From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.zx2c4.com (lists.zx2c4.com [165.227.139.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C6A8AC27C4F for ; Fri, 21 Jun 2024 14:42:07 +0000 (UTC) Received: by lists.zx2c4.com (ZX2C4 Mail Server) with ESMTP id c6542402; Fri, 21 Jun 2024 14:42:05 +0000 (UTC) Received: from w4.tutanota.de (w4.tutanota.de [81.3.6.165]) by lists.zx2c4.com (ZX2C4 Mail Server) with ESMTPS id c761e9a6 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Fri, 21 Jun 2024 14:42:03 +0000 (UTC) Received: from tutadb.w10.tutanota.de (unknown [192.168.1.10]) by w4.tutanota.de (Postfix) with ESMTP id CBA4510600BC; Fri, 21 Jun 2024 14:42:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1718980922; s=s1; d=diyaa.ca; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=xqMNnPy7Wg/THtSTDjqDdQoRFOn1H3mfyrLLpcdArJM=; b=3ClyOiiHz+ydwrne61t0jogAP5KvFQw1YSrJcFrKBtp/9SuuiuwK+ILD5M9EZlnF a5IvlwlDmZ/RAJRzCD/Jk+GYXNx3oJYlNV4g7cMTO19LlfBSI5Alt2iQzvDwd5mpnzF Q2BrEDsHY8o9FlItXkmISmkeQ1DDt8skO0Zc+EwvZaEPiowLWYyxvKPAlGMCAfcRbNf fWUKEhxicuT5sB1hlEEvr54/KOB7tqxf/wFdiRoSq1wWh8hQSPQUqgsKu94eQapQYQV QAUDCNxSuBFF0P9jQuoytz52k8M5QDrwJ+aofeSxS/KOJ+vLE3jNB/D+5XgsHyO6neb IEsLRmdJag== Date: Fri, 21 Jun 2024 16:42:02 +0200 (CEST) From: Diyaa Alkanakre To: Nico Schottelius Cc: WireGuard mailing list Message-ID: In-Reply-To: <878qyyim5k.fsf@ungleich.ch> References: <878qyyim5k.fsf@ungleich.ch> Subject: Re: Wireguard uses incorrect interface - routing issue MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: wireguard@lists.zx2c4.com X-Mailman-Version: 2.1.30rc1 Precedence: list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: wireguard-bounces@lists.zx2c4.com Sender: "WireGuard" The better approach would be to exclude the IPs from your WireGuard AllowedIPs. I always exclude IPs if I can before doing policy based routing. https://www.procustodibus.com/blog/2021/03/wireguard-allowedips-calculator/ Jun 21, 2024, 5:15 AM by nico.schottelius@ungleich.ch: > > Hello again, > > I'm sorry to flood the mailing list with wireguard bugs, but it seems > there is yet another routing bug in wireguard - happy to be wrong, but > here are my findings: > > a) system has source based routing on via ip rule: > > [11:07] server141.place10:~# ip rule ls > 0: from all lookup local > 32765: from 192.168.1.0/24 lookup 42 > 32766: from all lookup main > 32767: from all lookup default > [11:07] server141.place10:~# ip route sh table 42 > 194.5.220.0/24 via 192.168.1.254 dev eth1 proto bird metric 32 > 194.187.90.23 via 192.168.1.254 dev eth1 proto bird metric 32 > 212.103.65.231 via 192.168.1.254 dev eth1 proto bird metric 32 > [11:08] server141.place10:~# > > This should ensure that packets towards 194.187.90.23 travel via eth1. > > b) tcpdump for verification > > Using "tcpdump -ni any port 4000" I observe: > > 11:10:22.445638 eth0 Out IP 192.168.1.149.58591 > 194.187.90.23.4000: UDP, length 148 > 11:10:27.447026 eth0 Out IP 192.168.1.149.58591 > 194.187.90.23.4000: UDP, length 148 > 11:10:32.448329 eth0 Out IP 192.168.1.149.58591 > 194.187.90.23.4000: UDP, length 148 > 11:10:37.449719 eth0 Out IP 192.168.1.149.58591 > 194.187.90.23.4000: UDP, length 148 > > c) Route in main table > > There is indeed a route in the main routing table that matches, too: > > [11:08] server141.place10:~# ip r get 194.187.90.23 > 194.187.90.23 via 10.5.2.123 dev eth0 src 192.168.1.149 uid 0 > cache > > d) ip rule not working (?) > > So from what I can observe it is that ip rule does not work together > with wireguard / wireguard routing takes the route from main fib instead > of from the separate table. > > I am not sure if this is related at all to the IP address binding bug, > but it appears in a similar context from our tests. > > BR, > > Nico > > -- > Sustainable and modern Infrastructures by ungleich.ch >