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 1FB21C2BB85 for ; Fri, 21 Jun 2024 15:48:04 +0000 (UTC) Received: by lists.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 7a5a67c5; Fri, 21 Jun 2024 15:45:22 +0000 (UTC) Received: from smtp.ungleich.ch (smtp.ungleich.ch [2a0a:e5c0:2:2:0:c8ff:fe68:bf1c]) by lists.zx2c4.com (ZX2C4 Mail Server) with ESMTPS id be6b3dd5 (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO) for ; Fri, 21 Jun 2024 15:45:20 +0000 (UTC) Received: from nb3.localdomain (localhost [IPv6:::1]) by smtp.ungleich.ch (Postfix) with ESMTP id 9397320C9C; Fri, 21 Jun 2024 17:45:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ungleich.ch; s=202201; t=1718984719; bh=hLzyKJkVI6oINS/F5s921YWb1H7Z5PaY5pU6w/iDQ+0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ElUIlA/FLmYVwFWJgYogS00u1B7DInxGnMyCijjNC6gXLwOwFXitTl2Cb4Ec/yYVr wZW3kyT00qLUEZebXOAzb2/6uAOJf4F2ZWODVDebRObXfxUzLcvvqJRbNzKBjrDLQC 4Wun0kBgT+MlW0jlGsaKuvbOIKqDOFO04IiTVckn7H1LnugOLSHvhrX+56aSglWTqA ZDApC0moq5SDmRKGoUzCRjQc7rC4I55qSoFwc3bm5NIzE8v/+pG5tEZjhGBM7njjWd w5t2uNQhhygSBgHJDgSkmOD3bf1tVRk3qQk2Q6wXBc18ACGxRyxYW/I3cdEEtd8MyR MzLsw+gml4uoA== Received: by nb3.localdomain (Postfix, from userid 1000) id 7D04514C01B9; Fri, 21 Jun 2024 17:39:01 +0200 (CEST) From: Nico Schottelius To: Diyaa Alkanakre Cc: WireGuard mailing list Subject: Re: Wireguard uses incorrect interface - routing issue In-Reply-To: (Diyaa Alkanakre's message of "Fri, 21 Jun 2024 16:42:02 +0200 (CEST)") References: <878qyyim5k.fsf@ungleich.ch> Date: Fri, 21 Jun 2024 17:38:56 +0200 Message-ID: <87jzii8fvz.fsf@ungleich.ch> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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" --=-=-= Content-Type: text/plain Diyaa, this is about the *outside* tunnel IP address that wireguard uses to establish connection, not about inside routing. BR, Nico Diyaa Alkanakre writes: > 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 >> --=-=-= Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --==-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable =2D-=20 Sustainable and modern Infrastructures by ungleich.ch --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJRBAEBCgA7FiEEZZsNkehufiT9FWnQxykhoSk/LSQFAmZ1npAdHG5pY28uc2No b3R0ZWxpdXNAdW5nbGVpY2guY2gACgkQxykhoSk/LSQ64Q//STDOJ/Jcozp2v5TK a5ialGMjlgr9tN9KG7vUflM7HRMVgL3ou83MYNunF1AgiYBTEWBl0Mhn+D7i+6EB apvuN+k/o69ucwl9q4XFqfwpjv3CKXvTWeaRn1pshIIc8TLsCRxxIOU+LFLBLp1B f3bev/0rwsVKnPY+yYqdG+K4Lofrc3OOdijK0TJzveNEpEoojx7LgsBFSJTyqrab QlL+8tO66cf/MakHNJFHEKeLKMpy3xEJbqGxoGFq8mDgkVJYp3AB/5ZpuY2KMnpA o7MUANJl/Vrb3iNWusF5HwL/Kp8Lm1anc9PAdPKEZ4WixAUKkLB8nl/C6nC9htFD nog3JhyDsI9y4SEhEvE6pN6b6iCb2A7s5wfw4lDkiiOR4Wcd7bAKioFLu6VIchL2 giC3Yikvn6yqyPGRUhxhBqmy8aOBYfalxcFjw6hsdM8aHYqlooDhr+MAn/LEeuVO RkDzh2lvKn/LMvMTOLvJ7+SqTl9YqwhXQl1pAwQLh3V68QVnRKCaj8UXdFp6SGRV xAbO8EDwmstMqY8n6OEZh5UjdfAxY3DuioJjsmKu3aKVZ/bMheEstP9v0QA8Vapq pLUONjzpqMXxUBRj8k42B99HW88V5F29T1FIKYIegE2S8MZ0AfVMEp5XfvtzX2g8 JCQutt5guPpUOJNZWqdhiNqquq0= =u84A -----END PGP SIGNATURE----- --==-=-=-- --=-=-=--