* 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).