Wireguard broken with ip rule due to missing address binding
Nico Schottelius
nico.schottelius at ungleich.ch
Wed Jun 19 09:42:34 UTC 2024
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20240619/b06e6b4c/attachment.sig>
More information about the WireGuard
mailing list