Development discussion of WireGuard
 help / color / mirror / Atom feed
* ipv6 connexion fail - ipv4 OK
@ 2021-08-25 15:25 Daniel
  2021-08-26 11:14 ` Daniel
  0 siblings, 1 reply; 17+ messages in thread
From: Daniel @ 2021-08-25 15:25 UTC (permalink / raw)
  To: wireguard

Hi list,

I setup wireguard on a server running Debian 11 and get it to work with 
2 clients (Debian 11 and Ubuntu 20.04). Clients and server are on 
separate networks, one client behind a FW the other direct on Internet, 
no FW at all (VPS).

With this setup and ipv4 connection to the public IP of the server, 
everything is working as expected, ipv4 as well as ipv6 are passing 
smoothly.

Now I want to connect using the ipv6 address of the wg interface as both 
clients and server have ULA ipv6. This fail, wg show that connection is 
established but VPN is not usable. It's not a FW problem as I can ssh to 
the ipv6 address, as well as a netcat test from/to server IP -from each 
client- on an UDP port is working properly. Also, 
net.ipv6.conf.all.forwarding=1 is activated in sysctl.conf

All network stuff is done in /etc/network/interfaces which call the 
config file. The ipv6 address of the server is affected _to the 
wireguard interface_ (in ipv4 it's another interface who take care of 
the public address)

Server version is wireguard-tools v1.0.20210223.

If someone have any hint, thanks to share ;)
-- 
Daniel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ipv6 connexion fail - ipv4 OK
  2021-08-25 15:25 ipv6 connexion fail - ipv4 OK Daniel
@ 2021-08-26 11:14 ` Daniel
  2021-08-27 16:14   ` Roman Mamedov
  0 siblings, 1 reply; 17+ messages in thread
From: Daniel @ 2021-08-26 11:14 UTC (permalink / raw)
  To: wireguard

Correction

Le 25/08/2021 à 17:25, Daniel a écrit :
> Hi list,
> 
> I setup wireguard on a server running Debian 11 and get it to work with 
> 2 clients (Debian 11 and Ubuntu 20.04). Clients and server are on 
> separate networks, one client behind a FW the other direct on Internet, 
> no FW at all (VPS).
> 
> With this setup and ipv4 connection to the public IP of the server, 
> everything is working as expected, ipv4 as well as ipv6 are passing 
> smoothly.
> 
> Now I want to connect using the ipv6 address of the wg interface as both 
> clients and server have ULA ipv6.

Here is GUA to read.

> This fail, wg show that connection is 
> established but VPN is not usable. It's not a FW problem as I can ssh to 
> the ipv6 address, as well as a netcat test from/to server IP -from each 
> client- on an UDP port is working properly. Also, 
> net.ipv6.conf.all.forwarding=1 is activated in sysctl.conf
> 
> All network stuff is done in /etc/network/interfaces which call the 
> config file. The ipv6 address of the server is affected _to the 
> wireguard interface_ (in ipv4 it's another interface who take care of 
> the public address)
> 
> Server version is wireguard-tools v1.0.20210223.
> 
> If someone have any hint, thanks to share ;)

-- 
Daniel Huhardeaux
+33.368460088@tootai.net	      sip:820@sip.tootai.net
+41.445532125@swiss-itech.ch		    tootaiNET

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ipv6 connexion fail - ipv4 OK
  2021-08-26 11:14 ` Daniel
@ 2021-08-27 16:14   ` Roman Mamedov
  2021-08-27 17:16     ` Daniel
  0 siblings, 1 reply; 17+ messages in thread
From: Roman Mamedov @ 2021-08-27 16:14 UTC (permalink / raw)
  To: Daniel; +Cc: wireguard

On Thu, 26 Aug 2021 13:14:00 +0200
Daniel <tech@tootai.net> wrote:

> Correction
> 
> Le 25/08/2021 à 17:25, Daniel a écrit :
> > Hi list,
> > 
> > I setup wireguard on a server running Debian 11 and get it to work with 
> > 2 clients (Debian 11 and Ubuntu 20.04). Clients and server are on 
> > separate networks, one client behind a FW the other direct on Internet, 
> > no FW at all (VPS).
> > 
> > With this setup and ipv4 connection to the public IP of the server, 
> > everything is working as expected, ipv4 as well as ipv6 are passing 
> > smoothly.
> > 
> > Now I want to connect using the ipv6 address of the wg interface as both 
> > clients and server have ULA ipv6.
> 
> Here is GUA to read.
> 
> > This fail, wg show that connection is 
> > established but VPN is not usable. It's not a FW problem as I can ssh to 
> > the ipv6 address, as well as a netcat test from/to server IP -from each 
> > client- on an UDP port is working properly. Also, 
> > net.ipv6.conf.all.forwarding=1 is activated in sysctl.conf
> > 
> > All network stuff is done in /etc/network/interfaces which call the 
> > config file. The ipv6 address of the server is affected _to the 
> > wireguard interface_ (in ipv4 it's another interface who take care of 
> > the public address)
> > 
> > Server version is wireguard-tools v1.0.20210223.
> > 
> > If someone have any hint, thanks to share ;)
> 

IPv6 requires the in-WG MTU to be 20 bytes less than when running over IPv4.
Try reducing it accordingly.

-- 
With respect,
Roman

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ipv6 connexion fail - ipv4 OK
  2021-08-27 16:14   ` Roman Mamedov
@ 2021-08-27 17:16     ` Daniel
  2021-08-27 21:35       ` [Warning: DMARC Fail Email] " Mike O'Connor
  0 siblings, 1 reply; 17+ messages in thread
From: Daniel @ 2021-08-27 17:16 UTC (permalink / raw)
  To: wireguard

Hi ROman

Le 27/08/2021 à 18:14, Roman Mamedov a écrit :
> On Thu, 26 Aug 2021 13:14:00 +0200
> Daniel <tech@tootai.net> wrote:
>
>> Correction
>>
>> Le 25/08/2021 à 17:25, Daniel a écrit :
>>> Hi list,
>>>
>>> I setup wireguard on a server running Debian 11 and get it to work with
>>> 2 clients (Debian 11 and Ubuntu 20.04). Clients and server are on
>>> separate networks, one client behind a FW the other direct on Internet,
>>> no FW at all (VPS).
>>>
>>> With this setup and ipv4 connection to the public IP of the server,
>>> everything is working as expected, ipv4 as well as ipv6 are passing
>>> smoothly.
>>>
>>> Now I want to connect using the ipv6 address of the wg interface as both
>>> clients and server have ULA ipv6.
>> Here is GUA to read.
>>
>>> This fail, wg show that connection is
>>> established but VPN is not usable. It's not a FW problem as I can ssh to
>>> the ipv6 address, as well as a netcat test from/to server IP -from each
>>> client- on an UDP port is working properly. Also,
>>> net.ipv6.conf.all.forwarding=1 is activated in sysctl.conf
>>>
>>> All network stuff is done in /etc/network/interfaces which call the
>>> config file. The ipv6 address of the server is affected _to the
>>> wireguard interface_ (in ipv4 it's another interface who take care of
>>> the public address)
>>>
>>> Server version is wireguard-tools v1.0.20210223.
>>>
>>> If someone have any hint, thanks to share ;)
> IPv6 requires the in-WG MTU to be 20 bytes less than when running over IPv4.
> Try reducing it accordingly.

Tried 1400, 1396 and 1392, problem stay.

Thanks for your help

-- 
Daniel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK
  2021-08-27 17:16     ` Daniel
@ 2021-08-27 21:35       ` Mike O'Connor
  2021-08-27 21:44         ` Roman Mamedov
  0 siblings, 1 reply; 17+ messages in thread
From: Mike O'Connor @ 2021-08-27 21:35 UTC (permalink / raw)
  To: Daniel, wireguard

Hi

On a 1500 link I'm having to use 1280 to get ipv6 to successfully go 
over a wireguard link.

I really think wireguard should be able to fragment and send via 
multiply UDP packets.

wireguard works very well other than this issue, performance is 
extremely good.

Mike

On 28/8/21 2:46 am, Daniel wrote:
> Hi ROman
>
> Le 27/08/2021 à 18:14, Roman Mamedov a écrit :
>> On Thu, 26 Aug 2021 13:14:00 +0200
>> Daniel <tech@tootai.net> wrote:
>>
>>> Correction
>>>
>>> Le 25/08/2021 à 17:25, Daniel a écrit :
>>>> Hi list,
>>>>
>>>> I setup wireguard on a server running Debian 11 and get it to work 
>>>> with
>>>> 2 clients (Debian 11 and Ubuntu 20.04). Clients and server are on
>>>> separate networks, one client behind a FW the other direct on 
>>>> Internet,
>>>> no FW at all (VPS).
>>>>
>>>> With this setup and ipv4 connection to the public IP of the server,
>>>> everything is working as expected, ipv4 as well as ipv6 are passing
>>>> smoothly.
>>>>
>>>> Now I want to connect using the ipv6 address of the wg interface as 
>>>> both
>>>> clients and server have ULA ipv6.
>>> Here is GUA to read.
>>>
>>>> This fail, wg show that connection is
>>>> established but VPN is not usable. It's not a FW problem as I can 
>>>> ssh to
>>>> the ipv6 address, as well as a netcat test from/to server IP -from 
>>>> each
>>>> client- on an UDP port is working properly. Also,
>>>> net.ipv6.conf.all.forwarding=1 is activated in sysctl.conf
>>>>
>>>> All network stuff is done in /etc/network/interfaces which call the
>>>> config file. The ipv6 address of the server is affected _to the
>>>> wireguard interface_ (in ipv4 it's another interface who take care of
>>>> the public address)
>>>>
>>>> Server version is wireguard-tools v1.0.20210223.
>>>>
>>>> If someone have any hint, thanks to share ;)
>> IPv6 requires the in-WG MTU to be 20 bytes less than when running 
>> over IPv4.
>> Try reducing it accordingly.
>
> Tried 1400, 1396 and 1392, problem stay.
>
> Thanks for your help
>


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK
  2021-08-27 21:35       ` [Warning: DMARC Fail Email] " Mike O'Connor
@ 2021-08-27 21:44         ` Roman Mamedov
  2021-08-27 21:54           ` Mike O'Connor
  2021-08-30 10:24           ` Daniel
  0 siblings, 2 replies; 17+ messages in thread
From: Roman Mamedov @ 2021-08-27 21:44 UTC (permalink / raw)
  To: Mike O'Connor; +Cc: Daniel, wireguard

On Sat, 28 Aug 2021 07:05:45 +0930
Mike O'Connor <mike@pineview.net> wrote:

> On a 1500 link I'm having to use 1280 to get ipv6 to successfully go 
> over a wireguard link.

Then it is not a true 1500 MTU link, something in-between drops packets at a
lower bar. Or maybe not all of them, but just UDP, for example.

But yeah, 1280 is worth trying as well, maybe Daniel has a similar issue.

As for me I am using MTU 1412 WG over IPv6 on a 1492 MTU underlying link just
fine.

> I really think wireguard should be able to fragment and send via 
> multiply UDP packets.

It is able to, as long as the underlying link MTU is set to a correct value
(i.e. where largest-sized packets actually go through, and not get silently
dropped).

-- 
With respect,
Roman

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK
  2021-08-27 21:44         ` Roman Mamedov
@ 2021-08-27 21:54           ` Mike O'Connor
  2021-08-30 10:24           ` Daniel
  1 sibling, 0 replies; 17+ messages in thread
From: Mike O'Connor @ 2021-08-27 21:54 UTC (permalink / raw)
  To: Roman Mamedov; +Cc: Daniel, wireguard

root@gw:~# ping -M do -s 1472 13.17.1.2
PING 103.127.123.217 (13.17.1.2) 1472(1500) bytes of data.
1480 bytes from 13.17.1.2: icmp_seq=1 ttl=60 time=7.93 ms

Link can transmit a max of 1500 bytes as seen above.

Pinging a LAN segment has the same limit. ie PC to PC has the same result.

Mike

On 28/8/21 7:14 am, Roman Mamedov wrote:
> On Sat, 28 Aug 2021 07:05:45 +0930
> Mike O'Connor <mike@pineview.net> wrote:
>
>> On a 1500 link I'm having to use 1280 to get ipv6 to successfully go
>> over a wireguard link.
> Then it is not a true 1500 MTU link, something in-between drops packets at a
> lower bar. Or maybe not all of them, but just UDP, for example.
>
> But yeah, 1280 is worth trying as well, maybe Daniel has a similar issue.
>
> As for me I am using MTU 1412 WG over IPv6 on a 1492 MTU underlying link just
> fine.
>
>> I really think wireguard should be able to fragment and send via
>> multiply UDP packets.
> It is able to, as long as the underlying link MTU is set to a correct value
> (i.e. where largest-sized packets actually go through, and not get silently
> dropped).
>


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK
  2021-08-27 21:44         ` Roman Mamedov
  2021-08-27 21:54           ` Mike O'Connor
@ 2021-08-30 10:24           ` Daniel
  2021-08-30 12:55             ` Skyler Mäntysaari
  2021-08-30 16:43             ` Roman Mamedov
  1 sibling, 2 replies; 17+ messages in thread
From: Daniel @ 2021-08-30 10:24 UTC (permalink / raw)
  To: wireguard

Hi

Le 27/08/2021 à 23:44, Roman Mamedov a écrit :
> On Sat, 28 Aug 2021 07:05:45 +0930
> Mike O'Connor <mike@pineview.net> wrote:
>
>> On a 1500 link I'm having to use 1280 to get ipv6 to successfully go
>> over a wireguard link.
> Then it is not a true 1500 MTU link, something in-between drops packets at a
> lower bar. Or maybe not all of them, but just UDP, for example.
>
> But yeah, 1280 is worth trying as well, maybe Daniel has a similar issue.
>
> As for me I am using MTU 1412 WG over IPv6 on a 1492 MTU underlying link just
> fine.

After lot of few testings, I think the problem is elsewhere. Setup of 
the server:

. eth0 with one public ipv4 IP and ipv6 /64

. 2 tunnels (one gre, one sit), each of them having one ipv4 and one 
ipv6 /64. They take care on trafic from/to our /48 ipv6 range

. 2 tun openvpn interfaces for customers with ipv6 address from our /48 
range

. wireguard interface with ipv6 address from our /48 range

Using tcpdump -i any I see the trafic coming to the gre interface and 
that's all. But netstat show

udp6       0      0 :::12345 :::*                                
0          125391     -

and ps aux output is

dh@peech:~$ ps ax|grep wg
    6969 ?        I<     0:00 [wg-crypt-wig4to]
    7026 ?        I      0:00 [kworker/1:2-wg-kex-wig4tootai]

Question: is wireguard really listening on all ipv6 addresses ? If not, 
how is the address choosen ?

[...]

Thanks for your help

-- 
Daniel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK
  2021-08-30 10:24           ` Daniel
@ 2021-08-30 12:55             ` Skyler Mäntysaari
  2021-08-30 16:43             ` Roman Mamedov
  1 sibling, 0 replies; 17+ messages in thread
From: Skyler Mäntysaari @ 2021-08-30 12:55 UTC (permalink / raw)
  To: wireguard

On 8/30/21 1:24 PM, Daniel wrote:

> Hi
>
> Le 27/08/2021 à 23:44, Roman Mamedov a écrit :
>> On Sat, 28 Aug 2021 07:05:45 +0930
>> Mike O'Connor <mike@pineview.net> wrote:
>>
>>> On a 1500 link I'm having to use 1280 to get ipv6 to successfully go
>>> over a wireguard link.
>> Then it is not a true 1500 MTU link, something in-between drops 
>> packets at a
>> lower bar. Or maybe not all of them, but just UDP, for example.
>>
>> But yeah, 1280 is worth trying as well, maybe Daniel has a similar 
>> issue.
>>
>> As for me I am using MTU 1412 WG over IPv6 on a 1492 MTU underlying 
>> link just
>> fine.
>
> After lot of few testings, I think the problem is elsewhere. Setup of 
> the server:
>
> . eth0 with one public ipv4 IP and ipv6 /64
>
> . 2 tunnels (one gre, one sit), each of them having one ipv4 and one 
> ipv6 /64. They take care on trafic from/to our /48 ipv6 range
>
> . 2 tun openvpn interfaces for customers with ipv6 address from our 
> /48 range
>
> . wireguard interface with ipv6 address from our /48 range
>
> Using tcpdump -i any I see the trafic coming to the gre interface and 
> that's all. But netstat show
>
> udp6       0      0 :::12345 :::* 0          125391     -
>
> and ps aux output is
>
> dh@peech:~$ ps ax|grep wg
>    6969 ?        I<     0:00 [wg-crypt-wig4to]
>    7026 ?        I      0:00 [kworker/1:2-wg-kex-wig4tootai]
>
> Question: is wireguard really listening on all ipv6 addresses ? If 
> not, how is the address choosen ?
>
> [...]
>
> Thanks for your help
>
Hi,

I'm having to use MSS 1380 for IPv4 and MSS 1360 for IPv6 with 
Wireguard, and it works great. However I'm not entirely sure what the 
underlying link MTU actually is because WAN says 1500, but pinging with 
`-m DO` sometimes doesn't work like it is in fact MTU 1500 all the way.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK
  2021-08-30 10:24           ` Daniel
  2021-08-30 12:55             ` Skyler Mäntysaari
@ 2021-08-30 16:43             ` Roman Mamedov
  2021-08-30 17:28               ` Daniel
  1 sibling, 1 reply; 17+ messages in thread
From: Roman Mamedov @ 2021-08-30 16:43 UTC (permalink / raw)
  To: Daniel; +Cc: wireguard

On Mon, 30 Aug 2021 12:24:01 +0200
Daniel <tech@tootai.net> wrote:

> Using tcpdump -i any I see the trafic coming to the gre interface and 
> that's all. But netstat show
> 
> udp6       0      0 :::12345 :::*                                
> 0          125391     -
> 
> and ps aux output is
> 
> dh@peech:~$ ps ax|grep wg
>     6969 ?        I<     0:00 [wg-crypt-wig4to]
>     7026 ?        I      0:00 [kworker/1:2-wg-kex-wig4tootai]
> 
> Question: is wireguard really listening on all ipv6 addresses ? If not, 
> how is the address choosen ?

Yes it does.


You seem to have some very complex setup, I suggest to look into whether you
send replies from the interface you expect them to. If you use wg-quick, maybe
switch to just wg and set up manually and with careful intent of each action,
as wg-quick might not have in mind some aspect of your setup.

-- 
With respect,
Roman

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK
  2021-08-30 16:43             ` Roman Mamedov
@ 2021-08-30 17:28               ` Daniel
  2021-08-30 17:38                 ` Roman Mamedov
  0 siblings, 1 reply; 17+ messages in thread
From: Daniel @ 2021-08-30 17:28 UTC (permalink / raw)
  To: wireguard


Le 30/08/2021 à 18:43, Roman Mamedov a écrit :
> On Mon, 30 Aug 2021 12:24:01 +0200
> Daniel <tech@tootai.net> wrote:
>
>> Using tcpdump -i any I see the trafic coming to the gre interface and
>> that's all. But netstat show
>>
>> udp6       0      0 :::12345 :::*
>> 0          125391     -
>>
>> and ps aux output is
>>
>> dh@peech:~$ ps ax|grep wg
>>      6969 ?        I<     0:00 [wg-crypt-wig4to]
>>      7026 ?        I      0:00 [kworker/1:2-wg-kex-wig4tootai]
>>
>> Question: is wireguard really listening on all ipv6 addresses ? If not,
>> how is the address choosen ?
> Yes it does.
>
>
> You seem to have some very complex setup, I suggest to look into whether you
> send replies from the interface you expect them to. If you use wg-quick, maybe
> switch to just wg and set up manually and with careful intent of each action,
> as wg-quick might not have in mind some aspect of your setup.

I don't use wg-quick: interface setup is done in interfaces file and 
reading conf file from there.

To be sure (and I think it is as I have no problem with ipv4):

. my interfaces are named wig4tootai our wigserver Nothing wrong here ?

. conf file are not named <interface name>.conf but server.conf or 
anyname.conf Nothing wrong here too ?

Conserning the setup, I made another one using one VPS (one public ipv4 and one ipv6 /64 range) but get the same result. No FW involved at all :(
-- 
Daniel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK
  2021-08-30 17:28               ` Daniel
@ 2021-08-30 17:38                 ` Roman Mamedov
  2021-08-30 17:44                   ` Daniel
  0 siblings, 1 reply; 17+ messages in thread
From: Roman Mamedov @ 2021-08-30 17:38 UTC (permalink / raw)
  To: Daniel; +Cc: wireguard

On Mon, 30 Aug 2021 19:28:11 +0200
Daniel <tech@tootai.net> wrote:

> To be sure (and I think it is as I have no problem with ipv4):
> 
> . my interfaces are named wig4tootai our wigserver Nothing wrong here ?
> 
> . conf file are not named <interface name>.conf but server.conf or 
> anyname.conf Nothing wrong here too ?

Interface names are arbitrary. As for proper .conf filenames on your system, I
am not sure, but you can simply check whether everything looks fine by running
the "wg" tool.

> Conserning the setup, I made another one using one VPS (one public ipv4 and
> one ipv6 /64 range) but get the same result. No FW involved at all :(

Do you get WG working at all, between some other two hosts (not involving this
particular server for now)?

-- 
With respect,
Roman

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK
  2021-08-30 17:38                 ` Roman Mamedov
@ 2021-08-30 17:44                   ` Daniel
  2021-08-30 17:59                     ` Roman Mamedov
  0 siblings, 1 reply; 17+ messages in thread
From: Daniel @ 2021-08-30 17:44 UTC (permalink / raw)
  To: wireguard


Le 30/08/2021 à 19:38, Roman Mamedov a écrit :
> On Mon, 30 Aug 2021 19:28:11 +0200
> Daniel <tech@tootai.net> wrote:
>
>> To be sure (and I think it is as I have no problem with ipv4):
>>
>> . my interfaces are named wig4tootai our wigserver Nothing wrong here ?
>>
>> . conf file are not named <interface name>.conf but server.conf or
>> anyname.conf Nothing wrong here too ?
> Interface names are arbitrary. As for proper .conf filenames on your system, I
> am not sure, but you can simply check whether everything looks fine by running
> the "wg" tool.
>
>> Conserning the setup, I made another one using one VPS (one public ipv4 and
>> one ipv6 /64 range) but get the same result. No FW involved at all :(
> 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.

-- 
Daniel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK
  2021-08-30 17:44                   ` Daniel
@ 2021-08-30 17:59                     ` Roman Mamedov
  2021-08-31 17:50                       ` Daniel
  2021-09-03 13:59                       ` ipv6 connexion fail - ipv4 OK (SOLVED) Daniel
  0 siblings, 2 replies; 17+ messages in thread
From: Roman Mamedov @ 2021-08-30 17:59 UTC (permalink / raw)
  To: Daniel; +Cc: wireguard

On Mon, 30 Aug 2021 19:44:21 +0200
Daniel <tech@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.

-- 
With respect,
Roman

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ipv6 connexion fail - ipv4 OK
  2021-08-30 17:59                     ` Roman Mamedov
@ 2021-08-31 17:50                       ` Daniel
  2021-09-01 17:44                         ` Daniel
  2021-09-03 13:59                       ` ipv6 connexion fail - ipv4 OK (SOLVED) Daniel
  1 sibling, 1 reply; 17+ messages in thread
From: Daniel @ 2021-08-31 17:50 UTC (permalink / raw)
  To: wireguard

Hi

Le 30/08/2021 à 19:59, Roman Mamedov a écrit :
> On Mon, 30 Aug 2021 19:44:21 +0200
> Daniel <tech@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 ;)

-- 
Daniel

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ipv6 connexion fail - ipv4 OK
  2021-08-31 17:50                       ` Daniel
@ 2021-09-01 17:44                         ` Daniel
  0 siblings, 0 replies; 17+ messages in thread
From: Daniel @ 2021-09-01 17:44 UTC (permalink / raw)
  To: wireguard

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 <tech@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

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: ipv6 connexion fail - ipv4 OK (SOLVED)
  2021-08-30 17:59                     ` Roman Mamedov
  2021-08-31 17:50                       ` Daniel
@ 2021-09-03 13:59                       ` Daniel
  1 sibling, 0 replies; 17+ messages in thread
From: Daniel @ 2021-09-03 13:59 UTC (permalink / raw)
  To: wireguard

Hello

Le 30/08/2021 à 19:59, Roman Mamedov a écrit :
> On Mon, 30 Aug 2021 19:44:21 +0200
> Daniel <tech@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 got it.

1. you can't use ipv6 IP from the range of /64 (or other) that you 
connect to. As workaround, I build an ULA/64 network to connect both 
ends using one ipv6 from the /64 range of the server to connect
2. once the tunnel is up nothing is shown on wg show until first packet 
arrive. If you try to ping from server to client -which was my case- you 
get an error destination address has to be specified. But as soon as the 
client has send a packet (ping or keepalive), tunnel is open both ways
3. the MTU I have to use is 1436

Thanks all for your help.

-- 
Daniel

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2021-09-03 13:59 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-25 15:25 ipv6 connexion fail - ipv4 OK Daniel
2021-08-26 11:14 ` Daniel
2021-08-27 16:14   ` Roman Mamedov
2021-08-27 17:16     ` Daniel
2021-08-27 21:35       ` [Warning: DMARC Fail Email] " Mike O'Connor
2021-08-27 21:44         ` Roman Mamedov
2021-08-27 21:54           ` Mike O'Connor
2021-08-30 10:24           ` Daniel
2021-08-30 12:55             ` Skyler Mäntysaari
2021-08-30 16:43             ` Roman Mamedov
2021-08-30 17:28               ` Daniel
2021-08-30 17:38                 ` Roman Mamedov
2021-08-30 17:44                   ` Daniel
2021-08-30 17:59                     ` Roman Mamedov
2021-08-31 17:50                       ` Daniel
2021-09-01 17:44                         ` Daniel
2021-09-03 13:59                       ` ipv6 connexion fail - ipv4 OK (SOLVED) Daniel

Development discussion of WireGuard

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://inbox.vuxu.org/wireguard \
		wireguard@lists.zx2c4.com
	public-inbox-index wireguard

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.wireguard


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git