Again :)

Le 31/08/2021 à 19:50, Daniel a écrit :
Hi

Le 30/08/2021 à 19:59, Roman Mamedov a écrit :
On Mon, 30 Aug 2021 19:44:21 +0200
Daniel <t...@tootai.net> wrote:

Do you get WG working at all, between some other two hosts (not involving this
particular server for now)?
Yes. Clients are shown on both sides as connected, trafic seems to go
out on each side but other one as received near to nothing.
I mean not just "shown as connected", but have you got actual traffic working between any two hosts. Even just forgetting this server for a while. So that you can rule out some general issue and concentrate on just the particular
machine setup.

I went a step further. Server has a /64 on eth0, his address being .1/64 Interface I gave to wireguard is called wigserver and get .a2/64 as address when up. Now I start the client which is a .24/64 while tcpdump -ni any udp and port 38194 is running on the server. Output is

19:28:45.790295 eth0  In  IP6 2001:db8:16e:10::24.50012 > 2001:db8:c2c:7c50::a2.38194: UDP, length 148 19:28:45.790629 eth0  Out IP6 2001:db8:c2c:7c50::a2.38194 > 2001:db8:16e:10::24.50012: UDP, length 92 19:29:06.572059 eth0  Out IP6 2001:db8:c2c:7c50::1.38194 > 2001:db8:16e:10::24.50012: UDP, length 148 19:29:11.947969 eth0  Out IP6 2001:db8:c2c:7c50::1.38194 > 2001:db8:16e:10::24.50012: UDP, length 148 19:29:17.324065 eth0  Out IP6 2001:db8:c2c:7c50::1.38194 > 2001:db8:16e:10::24.50012: UDP, length 148

As you can see, the original request is going to the right IP which respond with the right source IP (line 1 and 2) From here, all packets are going out with the IP of eth0 not the one from wigserver which is .a2/64. The client has "allowed ips = 10.99.98.0/27, ::/0"

Remember, no FW involved. Before this test I bring up interfaces without wireguard configuration and did server/client test like nc -lu IP PORT on the server while on the client I used nc -u IP PORT Everything worked well. I also started the client while server was not running and got the ICMP6 respons "unreachable port" sended to the client. I also tried to tell to the client to connect to the .1/64 insteed of the .a2/64, didn't work

If someone had an idea on what's going on here, would be helpful ;)

I continue my investigations and modify client to connect to eth0 ipv6 address .1/64 as well that I set debug using # modprobe wireguard && echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control command. I get the same result that when I connect to the .a2/64 IP address from the wireguard server.

Clearly, the first step seems to go well as I see

Sep  1 19:00:51 kirsch kernel: [ 3597.830187] wireguard: wigserver: Receiving handshake initiation from peer 1 ([2001:db8:16e:10::24]:42602/0%0) Sep  1 19:00:51 kirsch kernel: [ 3597.830193] wireguard: wigserver: Sending handshake response to peer 1 ([2001:db8:16e:10::24]:42602/0%0) Sep  1 19:00:51 kirsch kernel: [ 3597.830487] wireguard: wigserver: Keypair 1 created for peer 1

but then appear the problem, server did not receive the answer and try again and again and again. Please note that it tell 5s but it is in the same second or so.

Sep  1 19:00:52 kirsch kernel: [ 3599.369652] wireguard: wigserver: Handshake for peer 1 ([2001:db8:16e:10::24]:42602/0%0) did not complete after 5 seconds, r
etrying (try 13)

On the client, the answer is sended with the newly ipv6 address from the wireguard interface to the ipv6 address of the server wireguard interface

19:00:57.309251 IP6 2001:db8:c2c:7c50::24.42602 > 2001:db8:c2c:7c50::1.38194: UDP, length 148

and this too, again and again and again.

Hints ?

Thanks for your support

--
Daniel

Reply via email to