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