1

I have two computers on a robot that are directly connected via Ethernet. Called" Magni" and "Jetson". Magni is connected to a wireless network. On this wireless network, there is a third computer "PC" that is connected to the Magni via Wireguard VPN. I have two computers on a robot that are directly connected via Ethernet. Called" Magni" and "Jetson". Magni is connected to a wireless network. On this wireless network, there is a third computer "PC" that is connected to the Magni via Wireguard VPN.

Picture of Network Setup

The goal is to be able to send and receive messages from all components of the system to one another. The Magni - Jetson and Magni - PC pairs can ping, discover, and publish to each other. The issue I am having is communication between my PC and the Jetson. I attempted to do some IP forwarding. Where first on the jetson I added a route from the static 192.168.131.1 IP to the Magni's VPN 10.0.0.161. After doing so I am able to ping the Magni's VPN address 10.0.0.161 from the jetson.

sudo route add -net 10.0.0.0  netmask 255.255.255.0 gw 192.168.131.1

Then on my PC, I attempted to add a similar route...

sudo route add -net 192.168.131.0  netmask 255.255.255.0 gw 10.0.0.161

From my PC I then tried to communicate with the jetson (via ping). However, I am not able to successfully communicate with the Jetson. From the PC when trying to ping the Jetson, I get this error with my current set up.

PING 192.168.131.2 (10.0.0.66) 56(84) bytes of data.
From 10.0.0.66 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: Required key not available

I have also tried other routes to no avail. I was wondering if someone could point me in the right direction as to how to resolve this issue as I am not too experienced in networking.

PC's Kernel IP routing table

Destination   Gateway     Genmask       Flags Metric Ref    Use Iface

0.0.0.0           10.147.x.x      0.0.0.0         UG   600    0        0  wlp2s0

10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 wg0

10.147.x.x      0.0.0.0         255.255.0.0     U     600    0        0 wlp2s0

169.xxx.x.x     0.0.0.0         255.255.0.0     U     1000   0        0 wlp2s0

192.168.131.0   10.0.0.161      255.255.255.0   UG    0      0        0 wg0

Magni's Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         10.147.x.x      0.0.0.0         UG    600    0        0 wlan0

10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 wg0

10.19.xxx.xxx   10.147.x.x      255.255.255.255 UGH   600    0        0 wlan0

10.147.x.x      0.0.0.0         255.255.0.0     U     600    0        0 wlan0

192.168.131.0   0.0.0.0         255.255.255.0   U     0      0        0 enxb827eb452fa3

Jetson's Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.0.0.0           192.168.131.1   255.255.255.0   UG    0      0        0 eth0

169.xxx.x.x       0.0.0.0         255.255.0.0     U     1000   0        0 eth0

192.168.131.0   0.0.0.0         255.255.255.0   U     100    0        0 eth0
Improve this question
1
  • What about firewalls, IP forwarding, etc? How do you establish wireguard connection? Does wireguard make some additional routes? I had a very similar problem, and here is the solution: unix.stackexchange.com/questions/602267/…. I hope you can find something useful there. Commented Dec 28, 2020 at 8:05

1 Answer 1

Reset to default
1

ping: sendmsg: Required key not available means it's a WireGuard cryptokey routing issue. In WireGuard, the key has an association to the route and vice versa. This is an internal WireGuard routing made in addition to the standard routing:

At the heart of WireGuard is a concept called Cryptokey Routing, which works by associating public keys with a list of tunnel IP addresses that are allowed inside the tunnel.

That means you didn't add the required AllowedIPs (wg-quick) / allowed-ips (direct wg command) parameters.

When a WG interface is about to send a packet it matches the destination IP to a public key's AllowedIPs in order to encrypt it with this key. When a WG interface received a packet, it validates the source IP with the peer's public key's AllowedIPs: this value is used both ways.

To fix this, on the PC add in the configuration, under the relevant Magni Peer public key entry in the wg-quick configuration and restart the tunnel:

AllowedIPs = 192.168.131.0/24

Actually for this specific case AllowedIPs = 192.168.131.1,192.168.131.2 would be sufficient.

If you could already ping the Magni (192.168.131.1) from the PC, that should be enough, assuming Magni was set as router.

Else, there's the equivalent to do on the other WireGuard peer, Magni. Do the equivalent to match the PC, under the PC's Peer public key entry:

AllowedIPs = 10.0.0.0/24

Again AllowedIPs = 10.0.0.66 would be sufficient to reach only the PC here.

It could be done directly with a wg command instead for immediate (and not saved) effect (as an example a randomly generated Peer's public key value ukFU7nbX5NoEJTLb5rizqcfB093fv8VfuLFA57q3oG4= is used here, please change it to the PC's public key):

wg set wg0 peer ukFU7nbX5NoEJTLb5rizqcfB093fv8VfuLFA57q3oG4= allowed-ips 10.0.0.0/24
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.