* 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).