path: root/src/tests
diff options
authorJason A. Donenfeld <Jason@zx2c4.com>2017-08-11 23:28:44 +0200
committerJason A. Donenfeld <Jason@zx2c4.com>2017-08-23 09:05:19 -0600
commitaf2435d180ebb5a3d89b21eb9118d1c643f03f95 (patch)
tree8d9844d31b4f75d61419f867e494df322d88548b /src/tests
parentversion: bump snapshot (diff)
socket: improve reply-to-src algorithm
We store the destination IP of incoming packets as the source IP of outgoing packets. When we send outgoing packets, we then ask the routing table for which interface to use and which source address, given our inputs of the destination address and a suggested source address. This all is good and fine, since it means we'll successfully reply using the correct source address, correlating with the destination address for incoming packets. However, what happens when default routes change? Or when interface IP addresses change? Prior to this commit, after getting the response from the routing table of the source address, destination address, and interface, we would then make sure that the source address actually belonged to the outbound interface. If it didn't, we'd reset our source address to zero and re-ask the routing table, in which case the routing table would then give us the default IP address for sending that packet. This worked mostly fine for most purposes, but there was a problem: what if WireGuard legitimately accepted an inbound packet on a default interface using an IP of another interface? In this case, falling back to asking for the default source IP was not a good strategy, since it'd nearly always mean we'd fail to reply using the right source. So, this commit changes the algorithm slightly. Rather than falling back to using the default IP if the preferred source IP doesn't belong to the outbound interface, we have two checks: we make sure that the source IP address belongs to _some_ interface on the system, no matter which one (so long as it's within the network namespace), and we check whether or not the interface of an incoming packet matches the returned interface for the outbound traffic. If both these conditions are true, then we proceed with using this source IP address. If not, we fall back to the default IP address.
Diffstat (limited to 'src/tests')
2 files changed, 41 insertions, 0 deletions
diff --git a/src/tests/netns.sh b/src/tests/netns.sh
index 6a58b37..ea70fb5 100755
--- a/src/tests/netns.sh
+++ b/src/tests/netns.sh
@@ -322,6 +322,46 @@ n2 wg set wg0 peer "$pub1" endpoint [fd00:aa::2]:1
n2 ping -W 1 -c 1
[[ $(n2 wg show wg0 endpoints) == "$pub1 [fd00:aa::2]:1" ]]
+# What happens if the inbound destination address belongs to a different interface as the default route?
+ip1 link add dummy0 type dummy
+ip1 addr add dev dummy0
+ip1 link set dummy0 up
+ip2 route add dev veth2
+n2 wg set wg0 peer "$pub1" endpoint
+n2 ping -W 1 -c 1
+[[ $(n2 wg show wg0 endpoints) == "$pub1" ]]
+ip1 link del dummy0
+ip1 addr flush dev veth1
+ip2 addr flush dev veth2
+ip1 route flush dev veth1
+ip2 route flush dev veth2
+# Now we see what happens if another interface route takes precedence over an ongoing one
+ip1 link add veth3 type veth peer name veth4
+ip1 link set veth4 netns $netns2
+ip1 addr add dev veth1
+ip2 addr add dev veth2
+ip1 addr add dev veth3
+ip1 link set veth1 up
+ip2 link set veth2 up
+ip1 link set veth3 up
+ip2 link set veth4 up
+waitiface $netns1 veth1
+waitiface $netns2 veth2
+waitiface $netns1 veth3
+waitiface $netns2 veth4
+ip1 route flush dev veth1
+ip1 route flush dev veth3
+ip1 route add dev veth1 src metric 2
+n1 wg set wg0 peer "$pub2" endpoint
+n1 ping -W 1 -c 1
+[[ $(n2 wg show wg0 endpoints) == "$pub1" ]]
+ip1 route add dev veth3 src metric 1
+n1 ping -W 1 -c 1
+[[ $(n2 wg show wg0 endpoints) == "$pub1" ]]
ip1 link del veth1
+ip1 link del veth3
ip1 link del wg0
ip2 link del wg0
diff --git a/src/tests/qemu/kernel.config b/src/tests/qemu/kernel.config
index 5469448..84a9875 100644
--- a/src/tests/qemu/kernel.config
+++ b/src/tests/qemu/kernel.config
@@ -2,6 +2,7 @@ CONFIG_NET=y