lineageos 17.1after autostart on boot tunnel not functioning

lineageos 17.1after autostart on boot tunnel not functioning

[Chris]

I'm running the f-droid repo of the wireguard client on lineageos 17.1
When set auto autostart on boot, it does run.
The wireguard process is running and the tun0 interface is up with its setup ip 
address.

However the tunnel is not working. I can't ping the server.
After manually disabling and re-enabling the client everything is fine.
BR
Chris

Re: lineageos 17.1after autostart on boot tunnel not functioning

[Chris]

In answer to my own conribution and to further clarify the problem:
The server address was given as a DNS Name rather than an ip number.
Replacing it with the ip number, it works.
This probably means that wireguard tries to contact the server before DNS is 
functioning.
And this does not change!!
I never had this problem with openvpn.
Chris


On 26/09/2020 12:40, Chris wrote:
> I'm running the f-droid repo of the wireguard client on lineageos 17.1
> When set auto autostart on boot, it does run.
> The wireguard process is running and the tun0 interface is up with its setup 
> ip address.
>
> However the tunnel is not working. I can't ping the server.
> After manually disabling and re-enabling the client everything is fine.
> BR
> Chris
>

lineageos 17.1 no incoming

[Chris]

I'm running the f-droid repo of the wireguard client on lineageos 17.1
After the tunnel is up:
I can ping the wireguard client, and I can initiate an outgoing connection 
through the tunnel.

However, a process binding on all interfaces will not see any incoming traffic 
on tun0.
The same process works fine with incoming traffic on wlan0.

Sending the TCP SYN from the wireguard server through the tunnel, never receives 
an ACK.

Openvpn does not show this behaviour.

As the tun0 interface successfully reacts to pings, I guess it may be an 
iptables problem.
I.e. the traffic on tun0 is differently firewalled than the traffic on wlan0.

Chris

wg-quick up (on linux) fails in case of several default routes

[Chris]

In case there is more than one default route (with different metrics):

wg-quick tries to set the route to the wg server through the default gateway.
However, in case there is more than one default route it
fails setting the route to server correctly.

Instead it should run through the list of default gateways and set routes to the
wg server through ALL default gateways with a metric of the corresponding 
default route.
Chris

P.S.: Shall one report bugs here or rather at gitlab or both?

Re: wg-quick up (on linux) fails in case of several default routes

[Jason A. Donenfeld]

On Mon, Oct 5, 2020 at 3:51 PM Chris <wireguard@spam-free.eu> wrote:
> wg-quick tries to set the route to the wg server through the default gateway.

On Linux? It shouldn't be iterating default gateways at all, but
rather using suppress_prefix. Can you provide more technical
information about what you're seeing and maybe a patch to fix the
issue?

Jason

Re: wg-quick up (on linux) fails in case of several default routes

[Chris]

Hello Jason,

setup is
two default routes with diffenrent metrics (the second being the failover in 
case the lower metric connection goes down).
For good reasons wg-quick will setup an individual route to the wg server (for 
the possibility of changing th default route afterwards).
However wg-quick fails:

******log follows***********
wg-quick up wg_client
[#] ip link add wg_client type wireguard
[#] wg setconf wg_client /dev/fd/63
[#] ip -4 address add 10.0.129.200/24 dev wg_client
[#] ip link set mtu 1420 up dev wg_client
[#] GATEW=$(ip route list 0.0.0.0/0|sed -n 's/.* via \(.*\) dev.*/\1/p');route 
add s1.spam-free.eu gw $GATEW
SIOCADDRT: No such device
[#] ip link delete dev wg_client
******log  end  ***********

The point is, that GATEW is NOT a single address but rather a list of ip 
addresses and the command setting the route fails.

Instead one should always run through ALL default gateways and set individual 
routes to the server through ALL the default gateways with the same metric as 
the respective default route.
This will then also work in case the failover route is in operation.

Of course, tearing down the client should delete ALL individual routes to the 
server.
Hope this clarifies is a bit.

Cheers,
Chris

On 06/10/2020 14:20, Jason A. Donenfeld wrote:
> On Mon, Oct 5, 2020 at 3:51 PM Chris <wireguard@spam-free.eu> wrote:
>> wg-quick tries to set the route to the wg server through the default gateway.
> On Linux? It shouldn't be iterating default gateways at all, but
> rather using suppress_prefix. Can you provide more technical
> information about what you're seeing and maybe a patch to fix the
> issue?
>
> Jason

Re: wg-quick up (on linux) fails in case of several default routes

[Jason A. Donenfeld]

On 10/6/20, Chris <wireguard@spam-free.eu> wrote:
> Hello Jason,
>
> setup is
> two default routes with diffenrent metrics (the second being the failover in
>
> case the lower metric connection goes down).
> For good reasons wg-quick will setup an individual route to the wg server
> (for
> the possibility of changing th default route afterwards).
> However wg-quick fails:
>
> ******log follows***********
> wg-quick up wg_client
> [#] ip link add wg_client type wireguard
> [#] wg setconf wg_client /dev/fd/63
> [#] ip -4 address add 10.0.129.200/24 dev wg_client
> [#] ip link set mtu 1420 up dev wg_client
> [#] GATEW=$(ip route list 0.0.0.0/0|sed -n 's/.* via \(.*\)
> dev.*/\1/p');route
> add s1.spam-free.eu gw $GATEW
> SIOCADDRT: No such device

Where did you get your wg-quick? I would never name a variable 'GATEW'
or print out an expression like that to the console. IOW, I don't
recognize what's happening here because this doesn't seem to be code
I've shipped.


> [#] ip link delete dev wg_client
> ******log  end  ***********
>
> The point is, that GATEW is NOT a single address but rather a list of ip
> addresses and the command setting the route fails.
>
> Instead one should always run through ALL default gateways and set
> individual
> routes to the server through ALL the default gateways with the same metric
> as
> the respective default route.
> This will then also work in case the failover route is in operation.
>
> Of course, tearing down the client should delete ALL individual routes to
> the
> server.
> Hope this clarifies is a bit.
>
> Cheers,
> Chris
>
> On 06/10/2020 14:20, Jason A. Donenfeld wrote:
>> On Mon, Oct 5, 2020 at 3:51 PM Chris <wireguard@spam-free.eu> wrote:
>>> wg-quick tries to set the route to the wg server through the default
>>> gateway.
>> On Linux? It shouldn't be iterating default gateways at all, but
>> rather using suppress_prefix. Can you provide more technical
>> information about what you're seeing and maybe a patch to fix the
>> issue?
>>
>> Jason
>

Re: wg-quick up (on linux) fails in case of several default routes

[Chris]

Oh, this is veeery suprising, I did not expect that:
It is the standard recent ubuntu repo:

*************************
dpkg -S `which wg-quick`
wireguard-tools: /usr/bin/wg-quick

apt-cache policy wireguard-tools
wireguard-tools:
   Installed: 1.0.20200513-1~20.04.2
   Candidate: 1.0.20200513-1~20.04.2
   Version table:
  *** 1.0.20200513-1~20.04.2 500
         500 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages
         100 /var/lib/dpkg/status
      1.0.20200319-1ubuntu1 500
         500 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages
**************************


On 06/10/2020 15:47, Jason A. Donenfeld wrote:
> On 10/6/20, Chris <wireguard@spam-free.eu> wrote:
>> Hello Jason,
>>
>> setup is
>> two default routes with diffenrent metrics (the second being the failover in
>>
>> case the lower metric connection goes down).
>> For good reasons wg-quick will setup an individual route to the wg server
>> (for
>> the possibility of changing th default route afterwards).
>> However wg-quick fails:
>>
>> ******log follows***********
>> wg-quick up wg_client
>> [#] ip link add wg_client type wireguard
>> [#] wg setconf wg_client /dev/fd/63
>> [#] ip -4 address add 10.0.129.200/24 dev wg_client
>> [#] ip link set mtu 1420 up dev wg_client
>> [#] GATEW=$(ip route list 0.0.0.0/0|sed -n 's/.* via \(.*\)
>> dev.*/\1/p');route
>> add s1.spam-free.eu gw $GATEW
>> SIOCADDRT: No such device
> Where did you get your wg-quick? I would never name a variable 'GATEW'
> or print out an expression like that to the console. IOW, I don't
> recognize what's happening here because this doesn't seem to be code
> I've shipped.
>
>
>> [#] ip link delete dev wg_client
>> ******log  end  ***********
>>
>> The point is, that GATEW is NOT a single address but rather a list of ip
>> addresses and the command setting the route fails.
>>
>> Instead one should always run through ALL default gateways and set
>> individual
>> routes to the server through ALL the default gateways with the same metric
>> as
>> the respective default route.
>> This will then also work in case the failover route is in operation.
>>
>> Of course, tearing down the client should delete ALL individual routes to
>> the
>> server.
>> Hope this clarifies is a bit.
>>
>> Cheers,
>> Chris
>>
>> On 06/10/2020 14:20, Jason A. Donenfeld wrote:
>>> On Mon, Oct 5, 2020 at 3:51 PM Chris <wireguard@spam-free.eu> wrote:
>>>> wg-quick tries to set the route to the wg server through the default
>>>> gateway.
>>> On Linux? It shouldn't be iterating default gateways at all, but
>>> rather using suppress_prefix. Can you provide more technical
>>> information about what you're seeing and maybe a patch to fix the
>>> issue?
>>>
>>> Jason

Re: wg-quick up (on linux) fails in case of several default routes

[Jason A. Donenfeld]

Sounds like you put something silly into PostUp, then? Check your config file.

Re: wg-quick up (on linux) fails in case of several default routes

[Chris]

Your right, it was a stupid config file.
Sorry for any inconveniences.


On 06/10/2020 15:58, Jason A. Donenfeld wrote:
> Sounds like you put something silly into PostUp, then? Check your config file.