From: Nico Schottelius <nico.schottelius@ungleich.ch>
To: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Wireguard broken with ip rule due to missing address binding
Date: Wed, 19 Jun 2024 11:42:34 +0200 [thread overview]
Message-ID: <87h6dpi7zp.fsf@ungleich.ch> (raw)
[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]
Hello,
a follow up to the previous thread: if one uses "ip rule" for doing
source based routing, wireguard is broken / cannot be used
correctly. Let's take the following test case:
a) We have a separate VRF / routing table for wireguard endpoints
[09:35] 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
[09:37] 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
b) ping with a random IP address does not work (correct)
[09:35] server141.place10:~# ping -c2 194.187.90.23
PING 194.187.90.23 (194.187.90.23): 56 data bytes
--- 194.187.90.23 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
c) ping with the correct source ip address does work
[09:35] server141.place10:~# ping -I 192.168.1.149 -c2 194.187.90.23
PING 194.187.90.23 (194.187.90.23) from 192.168.1.149: 56 data bytes
64 bytes from 194.187.90.23: seq=0 ttl=57 time=3.883 ms
64 bytes from 194.187.90.23: seq=1 ttl=57 time=3.810 ms
--- 194.187.90.23 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.810/3.846/3.883 ms
[09:35] server141.place10:~#
d) wireguard does not work
[09:38] server141.place10:~# wg show
interface: oserver120
public key: EqrNWstRSdJnj1trm5KSWbVNxLi10w/ea2EbdADJSWU=
private key: (hidden)
listening port: 54658
peer: hUm9SGQnhOG7dPn4OuiGXJZ3Wk9UZZ9JdHd32HYyH0w=
endpoint: 194.187.90.23:4011
allowed ips: ::/0, 0.0.0.0/0
transfer: 0 B received, 8.09 KiB sent
[09:38] server141.place10:~#
From my perspective this is yet another bug that one encounters due to
missing IP address binding in wireguard.
And no, putting everything into a separate namespace is not an option,
because processes from the non namespaced part need access to the
tunnel.
I really hope the address binding issue can be solved soon, especially
giving there is already a patch for it available.
Best regards,
Nico
--
Sustainable and modern Infrastructures by ungleich.ch
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 873 bytes --]
next reply other threads:[~2024-06-19 9:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 9:42 Nico Schottelius [this message]
2024-06-19 10:01 ` Antonio Quartulli
2024-06-19 10:12 ` Nico Schottelius
2024-06-19 10:19 ` Antonio Quartulli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6dpi7zp.fsf@ungleich.ch \
--to=nico.schottelius@ungleich.ch \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).