[net-next,v11,05/23] ovpn: keep carrier always on

Commit Message

Antonio Quartulli Oct. 29, 2024, 10:47 a.m. UTC

An ovpn interface will keep carrier always on and let the user
decide when an interface should be considered disconnected.

This way, even if an ovpn interface is not connected to any peer,
it can still retain all IPs and routes and thus prevent any data
leak.

Signed-off-by: Antonio Quartulli <[e-mail]>
Reviewed-by: Andrew Lunn <[e-mail]>
---
 drivers/net/ovpn/main.c | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Sergey Ryazanov Nov. 9, 2024, 1:11 a.m. UTC | #1

On 29.10.2024 12:47, Antonio Quartulli wrote:
> An ovpn interface will keep carrier always on and let the user
> decide when an interface should be considered disconnected.
> 
> This way, even if an ovpn interface is not connected to any peer,
> it can still retain all IPs and routes and thus prevent any data
> leak.
> 
> Signed-off-by: Antonio Quartulli <[e-mail]>
> Reviewed-by: Andrew Lunn <[e-mail]>
> ---
>   drivers/net/ovpn/main.c | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/ovpn/main.c b/drivers/net/ovpn/main.c
> index eead7677b8239eb3c48bb26ca95492d88512b8d4..eaa83a8662e4ac2c758201008268f9633643c0b6 100644
> --- a/drivers/net/ovpn/main.c
> +++ b/drivers/net/ovpn/main.c
> @@ -31,6 +31,13 @@ static void ovpn_struct_free(struct net_device *net)
>   
>   static int ovpn_net_open(struct net_device *dev)
>   {
> +	/* ovpn keeps the carrier always on to avoid losing IP or route
> +	 * configuration upon disconnection. This way it can prevent leaks
> +	 * of traffic outside of the VPN tunnel.
> +	 * The user may override this behaviour by tearing down the interface
> +	 * manually.
> +	 */
> +	netif_carrier_on(dev);

If a user cares about the traffic leaking, then he can create a 
blackhole route with huge metric:

# ip route add blackhole default metric 10000

Why the network interface should implicitly provide this functionality? 
And on another hand, how a routing daemon can learn a topology change 
without indication from the interface?

>   	netif_tx_start_all_queues(dev);
>   	return 0;
>   }
>

Antonio Quartulli Nov. 15, 2024, 2:13 p.m. UTC | #2

On 09/11/2024 02:11, Sergey Ryazanov wrote:
> On 29.10.2024 12:47, Antonio Quartulli wrote:
>> An ovpn interface will keep carrier always on and let the user
>> decide when an interface should be considered disconnected.
>>
>> This way, even if an ovpn interface is not connected to any peer,
>> it can still retain all IPs and routes and thus prevent any data
>> leak.
>>
>> Signed-off-by: Antonio Quartulli <[e-mail]>
>> Reviewed-by: Andrew Lunn <[e-mail]>
>> ---
>>   drivers/net/ovpn/main.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/ovpn/main.c b/drivers/net/ovpn/main.c
>> index 
>> eead7677b8239eb3c48bb26ca95492d88512b8d4..eaa83a8662e4ac2c758201008268f9633643c0b6 100644
>> --- a/drivers/net/ovpn/main.c
>> +++ b/drivers/net/ovpn/main.c
>> @@ -31,6 +31,13 @@ static void ovpn_struct_free(struct net_device *net)
>>   static int ovpn_net_open(struct net_device *dev)
>>   {
>> +    /* ovpn keeps the carrier always on to avoid losing IP or route
>> +     * configuration upon disconnection. This way it can prevent leaks
>> +     * of traffic outside of the VPN tunnel.
>> +     * The user may override this behaviour by tearing down the 
>> interface
>> +     * manually.
>> +     */
>> +    netif_carrier_on(dev);
> 
> If a user cares about the traffic leaking, then he can create a 
> blackhole route with huge metric:
> 
> # ip route add blackhole default metric 10000
> 
> Why the network interface should implicitly provide this functionality? 
> And on another hand, how a routing daemon can learn a topology change 
> without indication from the interface?

This was discussed loooong ago with Andrew. Here my last response:

https://lore.kernel.org/all/[e-mail]/


Regards,

> 
>>       netif_tx_start_all_queues(dev);
>>       return 0;
>>   }
>>
>

Sergey Ryazanov Nov. 20, 2024, 10:56 p.m. UTC | #3

On 15.11.2024 16:13, Antonio Quartulli wrote:
> On 09/11/2024 02:11, Sergey Ryazanov wrote:
>> On 29.10.2024 12:47, Antonio Quartulli wrote:
>>> An ovpn interface will keep carrier always on and let the user
>>> decide when an interface should be considered disconnected.
>>>
>>> This way, even if an ovpn interface is not connected to any peer,
>>> it can still retain all IPs and routes and thus prevent any data
>>> leak.
>>>
>>> Signed-off-by: Antonio Quartulli <[e-mail]>
>>> Reviewed-by: Andrew Lunn <[e-mail]>
>>> ---
>>>   drivers/net/ovpn/main.c | 7 +++++++
>>>   1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/net/ovpn/main.c b/drivers/net/ovpn/main.c
>>> index 
>>> eead7677b8239eb3c48bb26ca95492d88512b8d4..eaa83a8662e4ac2c758201008268f9633643c0b6 100644
>>> --- a/drivers/net/ovpn/main.c
>>> +++ b/drivers/net/ovpn/main.c
>>> @@ -31,6 +31,13 @@ static void ovpn_struct_free(struct net_device *net)
>>>   static int ovpn_net_open(struct net_device *dev)
>>>   {
>>> +    /* ovpn keeps the carrier always on to avoid losing IP or route
>>> +     * configuration upon disconnection. This way it can prevent leaks
>>> +     * of traffic outside of the VPN tunnel.
>>> +     * The user may override this behaviour by tearing down the 
>>> interface
>>> +     * manually.
>>> +     */
>>> +    netif_carrier_on(dev);
>>
>> If a user cares about the traffic leaking, then he can create a 
>> blackhole route with huge metric:
>>
>> # ip route add blackhole default metric 10000
>>
>> Why the network interface should implicitly provide this 
>> functionality? And on another hand, how a routing daemon can learn a 
>> topology change without indication from the interface?
> 
> This was discussed loooong ago with Andrew. Here my last response:
> 
> https://lore.kernel.org/all/d896bbd8-2709-4834-a637- 
> [e-mail]/

Thank you for sharing the link to the beginning of the conversation. 
Till the moment we have 3 topics regarding the operational state indication:
1. possible absence of a conception of running state,
2. influence on routing protocol implementations,
3. traffic leaking.

As for conception of the running state, it should exists for tunneling 
protocols with a state tracking. In this specific case, we can assume 
interface running when it has configured peer with keys. The protocol 
even has nice feature for the connection monitoring - keepalive.

Routing protocols on one hand could benefit from the operational state 
indication. On another hand, hello/hold timer values mentioned in the 
documentation are comparable with default routing protocols timers. So, 
actual improvement is debatable.

Regarding the traffic leading, as I mentioned before, the blackhole 
route or a firewall rule works better then implicit blackholing with a 
non-running interface.

Long story short, I agree that we might not need a real operational 
state indication now. Still protecting from a traffic leaking is not 
good enough justification.

Andrew, what do you think? Is the traffic leaking prevention any good 
justification or it needs to be updated?

--
Sergey

Antonio Quartulli Nov. 21, 2024, 9:17 p.m. UTC | #4

On 20/11/2024 23:56, Sergey Ryazanov wrote:
> On 15.11.2024 16:13, Antonio Quartulli wrote:
>> On 09/11/2024 02:11, Sergey Ryazanov wrote:
>>> On 29.10.2024 12:47, Antonio Quartulli wrote:
>>>> An ovpn interface will keep carrier always on and let the user
>>>> decide when an interface should be considered disconnected.
>>>>
>>>> This way, even if an ovpn interface is not connected to any peer,
>>>> it can still retain all IPs and routes and thus prevent any data
>>>> leak.
>>>>
>>>> Signed-off-by: Antonio Quartulli <[e-mail]>
>>>> Reviewed-by: Andrew Lunn <[e-mail]>
>>>> ---
>>>>   drivers/net/ovpn/main.c | 7 +++++++
>>>>   1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/drivers/net/ovpn/main.c b/drivers/net/ovpn/main.c
>>>> index 
>>>> eead7677b8239eb3c48bb26ca95492d88512b8d4..eaa83a8662e4ac2c758201008268f9633643c0b6 100644
>>>> --- a/drivers/net/ovpn/main.c
>>>> +++ b/drivers/net/ovpn/main.c
>>>> @@ -31,6 +31,13 @@ static void ovpn_struct_free(struct net_device *net)
>>>>   static int ovpn_net_open(struct net_device *dev)
>>>>   {
>>>> +    /* ovpn keeps the carrier always on to avoid losing IP or route
>>>> +     * configuration upon disconnection. This way it can prevent leaks
>>>> +     * of traffic outside of the VPN tunnel.
>>>> +     * The user may override this behaviour by tearing down the 
>>>> interface
>>>> +     * manually.
>>>> +     */
>>>> +    netif_carrier_on(dev);
>>>
>>> If a user cares about the traffic leaking, then he can create a 
>>> blackhole route with huge metric:
>>>
>>> # ip route add blackhole default metric 10000
>>>
>>> Why the network interface should implicitly provide this 
>>> functionality? And on another hand, how a routing daemon can learn a 
>>> topology change without indication from the interface?
>>
>> This was discussed loooong ago with Andrew. Here my last response:
>>
>> https://lore.kernel.org/all/d896bbd8-2709-4834-a637- 
>> [e-mail]/
> 
> Thank you for sharing the link to the beginning of the conversation. 
> Till the moment we have 3 topics regarding the operational state 
> indication:
> 1. possible absence of a conception of running state,
> 2. influence on routing protocol implementations,
> 3. traffic leaking.
> 
> As for conception of the running state, it should exists for tunneling 
> protocols with a state tracking. In this specific case, we can assume 
> interface running when it has configured peer with keys. The protocol 
> even has nice feature for the connection monitoring - keepalive.

What about a device in MP mode? It doesn't make sense to turn the 
carrier off when the MP node has no peers connected.
At the same time I don't like having P2P and MP devices behaving 
differently in this regard.
Therefore keeping the carrier on seemed the most logical way forward (at 
least for now - we can still come back to this once we have something 
smarter to implement).

> 
> Routing protocols on one hand could benefit from the operational state 
> indication. On another hand, hello/hold timer values mentioned in the 
> documentation are comparable with default routing protocols timers. So, 
> actual improvement is debatable.
> 
> Regarding the traffic leading, as I mentioned before, the blackhole 
> route or a firewall rule works better then implicit blackholing with a 
> non-running interface.
> 
> Long story short, I agree that we might not need a real operational 
> state indication now. Still protecting from a traffic leaking is not 
> good enough justification.

Well, it's the so called "persistent interface" concept in VPNs: leave 
everything as is, even if the connection is lost.
I know it can be implemented in many other different ways..but I don't 
see a real problem with keeping this way.

A blackhole/firewall can still be added if the user prefers (and not use 
the persistent interface).

Regards,

> 
> Andrew, what do you think? Is the traffic leaking prevention any good 
> justification or it needs to be updated?
> 
> -- 
> Sergey

Sergey Ryazanov Nov. 23, 2024, 10:25 p.m. UTC | #5

On 21.11.2024 23:17, Antonio Quartulli wrote:
> On 20/11/2024 23:56, Sergey Ryazanov wrote:
>> On 15.11.2024 16:13, Antonio Quartulli wrote:
>>> On 09/11/2024 02:11, Sergey Ryazanov wrote:
>>>> On 29.10.2024 12:47, Antonio Quartulli wrote:
>>>>> An ovpn interface will keep carrier always on and let the user
>>>>> decide when an interface should be considered disconnected.
>>>>>
>>>>> This way, even if an ovpn interface is not connected to any peer,
>>>>> it can still retain all IPs and routes and thus prevent any data
>>>>> leak.
>>>>>
>>>>> Signed-off-by: Antonio Quartulli <[e-mail]>
>>>>> Reviewed-by: Andrew Lunn <[e-mail]>
>>>>> ---
>>>>>   drivers/net/ovpn/main.c | 7 +++++++
>>>>>   1 file changed, 7 insertions(+)
>>>>>
>>>>> diff --git a/drivers/net/ovpn/main.c b/drivers/net/ovpn/main.c
>>>>> index 
>>>>> eead7677b8239eb3c48bb26ca95492d88512b8d4..eaa83a8662e4ac2c758201008268f9633643c0b6 100644
>>>>> --- a/drivers/net/ovpn/main.c
>>>>> +++ b/drivers/net/ovpn/main.c
>>>>> @@ -31,6 +31,13 @@ static void ovpn_struct_free(struct net_device 
>>>>> *net)
>>>>>   static int ovpn_net_open(struct net_device *dev)
>>>>>   {
>>>>> +    /* ovpn keeps the carrier always on to avoid losing IP or route
>>>>> +     * configuration upon disconnection. This way it can prevent 
>>>>> leaks
>>>>> +     * of traffic outside of the VPN tunnel.
>>>>> +     * The user may override this behaviour by tearing down the 
>>>>> interface
>>>>> +     * manually.
>>>>> +     */
>>>>> +    netif_carrier_on(dev);
>>>>
>>>> If a user cares about the traffic leaking, then he can create a 
>>>> blackhole route with huge metric:
>>>>
>>>> # ip route add blackhole default metric 10000
>>>>
>>>> Why the network interface should implicitly provide this 
>>>> functionality? And on another hand, how a routing daemon can learn a 
>>>> topology change without indication from the interface?
>>>
>>> This was discussed loooong ago with Andrew. Here my last response:
>>>
>>> https://lore.kernel.org/all/d896bbd8-2709-4834-a637- 
>>> [e-mail]/
>>
>> Thank you for sharing the link to the beginning of the conversation. 
>> Till the moment we have 3 topics regarding the operational state 
>> indication:
>> 1. possible absence of a conception of running state,
>> 2. influence on routing protocol implementations,
>> 3. traffic leaking.
>>
>> As for conception of the running state, it should exists for tunneling 
>> protocols with a state tracking. In this specific case, we can assume 
>> interface running when it has configured peer with keys. The protocol 
>> even has nice feature for the connection monitoring - keepalive.
> 
> What about a device in MP mode? It doesn't make sense to turn the 
> carrier off when the MP node has no peers connected.
> At the same time I don't like having P2P and MP devices behaving 
> differently in this regard.

MP with a single network interface is an endless headache. Indeed. On 
the other hand, penalizing P2P users just because protocol support MP 
doesn't look like a solution either.

> Therefore keeping the carrier on seemed the most logical way forward (at 
> least for now - we can still come back to this once we have something 
> smarter to implement).

It was shown above how to distinguish between running and non-running cases.

If an author doesn't want to implement operational state indication now, 
then I'm Ok with it. Not a big deal now. I just don't like the idea to 
promote the abuse of the running state indicator. Please see below.

>> Routing protocols on one hand could benefit from the operational state 
>> indication. On another hand, hello/hold timer values mentioned in the 
>> documentation are comparable with default routing protocols timers. 
>> So, actual improvement is debatable.
>>
>> Regarding the traffic leading, as I mentioned before, the blackhole 
>> route or a firewall rule works better then implicit blackholing with a 
>> non-running interface.
>>
>> Long story short, I agree that we might not need a real operational 
>> state indication now. Still protecting from a traffic leaking is not 
>> good enough justification.
> 
> Well, it's the so called "persistent interface" concept in VPNs: leave 
> everything as is, even if the connection is lost.

It's called routing framework abuse. The IP router will choose the route 
and the egress interface not because this route is a good option to 
deliver a packet, but because someone trick it.

At some circumstance, e.g. Android app, it could be the only way to 
prevent traffic leaking. But these special circumstances do not make 
solution generic and eligible for inclusion into the mainline code.

> I know it can be implemented in many other different ways..but I don't 
> see a real problem with keeping this way.

At least routing protocols and network monitoring software will not be 
happy to see a dead interface pretending that it's still running. 
Generally speaking, saying that interface is running, when module knows 
for sure that a packet can not be delivered is a user misguiding.

> A blackhole/firewall can still be added if the user prefers (and not use 
> the persistent interface).

The solution with false-indication is not so reliable as it might look. 
Interface shutdown, inability of a user-space application to start, 
user-space application crash, user-space application restart, each of 
them will void the trick. Ergo, blackhole/firewall must be employed by a 
security concerned user. What makes the proposed feature odd.

To summaries, I'm Ok if this change will be merged with a comment like 
"For future study" or "To be done" or "To be implemented". But a comment 
like "to prevent traffic leaking" or any other comment implying a 
"breakthrough security feature" will have a big NACK from my side.

--
Sergey

Antonio Quartulli Nov. 23, 2024, 10:52 p.m. UTC | #6

On 23/11/2024 23:25, Sergey Ryazanov wrote:
> On 21.11.2024 23:17, Antonio Quartulli wrote:
>> On 20/11/2024 23:56, Sergey Ryazanov wrote:
>>> On 15.11.2024 16:13, Antonio Quartulli wrote:
>>>> On 09/11/2024 02:11, Sergey Ryazanov wrote:
>>>>> On 29.10.2024 12:47, Antonio Quartulli wrote:
>>>>>> An ovpn interface will keep carrier always on and let the user
>>>>>> decide when an interface should be considered disconnected.
>>>>>>
>>>>>> This way, even if an ovpn interface is not connected to any peer,
>>>>>> it can still retain all IPs and routes and thus prevent any data
>>>>>> leak.
>>>>>>
>>>>>> Signed-off-by: Antonio Quartulli <[e-mail]>
>>>>>> Reviewed-by: Andrew Lunn <[e-mail]>
>>>>>> ---
>>>>>>   drivers/net/ovpn/main.c | 7 +++++++
>>>>>>   1 file changed, 7 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/net/ovpn/main.c b/drivers/net/ovpn/main.c
>>>>>> index 
>>>>>> eead7677b8239eb3c48bb26ca95492d88512b8d4..eaa83a8662e4ac2c758201008268f9633643c0b6 100644
>>>>>> --- a/drivers/net/ovpn/main.c
>>>>>> +++ b/drivers/net/ovpn/main.c
>>>>>> @@ -31,6 +31,13 @@ static void ovpn_struct_free(struct net_device 
>>>>>> *net)
>>>>>>   static int ovpn_net_open(struct net_device *dev)
>>>>>>   {
>>>>>> +    /* ovpn keeps the carrier always on to avoid losing IP or route
>>>>>> +     * configuration upon disconnection. This way it can prevent 
>>>>>> leaks
>>>>>> +     * of traffic outside of the VPN tunnel.
>>>>>> +     * The user may override this behaviour by tearing down the 
>>>>>> interface
>>>>>> +     * manually.
>>>>>> +     */
>>>>>> +    netif_carrier_on(dev);
>>>>>
>>>>> If a user cares about the traffic leaking, then he can create a 
>>>>> blackhole route with huge metric:
>>>>>
>>>>> # ip route add blackhole default metric 10000
>>>>>
>>>>> Why the network interface should implicitly provide this 
>>>>> functionality? And on another hand, how a routing daemon can learn 
>>>>> a topology change without indication from the interface?
>>>>
>>>> This was discussed loooong ago with Andrew. Here my last response:
>>>>
>>>> https://lore.kernel.org/all/d896bbd8-2709-4834-a637- 
>>>> [e-mail]/
>>>
>>> Thank you for sharing the link to the beginning of the conversation. 
>>> Till the moment we have 3 topics regarding the operational state 
>>> indication:
>>> 1. possible absence of a conception of running state,
>>> 2. influence on routing protocol implementations,
>>> 3. traffic leaking.
>>>
>>> As for conception of the running state, it should exists for 
>>> tunneling protocols with a state tracking. In this specific case, we 
>>> can assume interface running when it has configured peer with keys. 
>>> The protocol even has nice feature for the connection monitoring - 
>>> keepalive.
>>
>> What about a device in MP mode? It doesn't make sense to turn the 
>> carrier off when the MP node has no peers connected.
>> At the same time I don't like having P2P and MP devices behaving 
>> differently in this regard.
> 
> MP with a single network interface is an endless headache. Indeed. On 
> the other hand, penalizing P2P users just because protocol support MP 
> doesn't look like a solution either.

On the upper side, with "iroutes" implemented using the system routing 
table, routing protocols will be able to detect new routes only when the 
related client has connected. (The same for the disconnection)

But this is a bit orthogonal compared to the oper state.

> 
>> Therefore keeping the carrier on seemed the most logical way forward 
>> (at least for now - we can still come back to this once we have 
>> something smarter to implement).
> 
> It was shown above how to distinguish between running and non-running 
> cases.
> 
> If an author doesn't want to implement operational state indication now, 
> then I'm Ok with it. Not a big deal now. I just don't like the idea to 
> promote the abuse of the running state indicator. Please see below.
> 
>>> Routing protocols on one hand could benefit from the operational 
>>> state indication. On another hand, hello/hold timer values mentioned 
>>> in the documentation are comparable with default routing protocols 
>>> timers. So, actual improvement is debatable.
>>>
>>> Regarding the traffic leading, as I mentioned before, the blackhole 
>>> route or a firewall rule works better then implicit blackholing with 
>>> a non-running interface.
>>>
>>> Long story short, I agree that we might not need a real operational 
>>> state indication now. Still protecting from a traffic leaking is not 
>>> good enough justification.
>>
>> Well, it's the so called "persistent interface" concept in VPNs: leave 
>> everything as is, even if the connection is lost.
> 
> It's called routing framework abuse. The IP router will choose the route 
> and the egress interface not because this route is a good option to 
> deliver a packet, but because someone trick it.

This is what the user wants.
OpenVPN (userspace) will tear down the P2P interface upon disconnection, 
assuming the --persist-tun option was not specified by the user.

So the interface is gone in any case.

By keeping the netcarrier on we are just ensuring that, if the user 
wanted persist-tun, the iface is not actually making decisions on its own.

With a tun interface this can be done, now you want to basically drop 
this feature that existed for long time and break existing setups.

> 
> At some circumstance, e.g. Android app, it could be the only way to 
> prevent traffic leaking. But these special circumstances do not make 
> solution generic and eligible for inclusion into the mainline code.

Why not? We are not changing the general rule, but just defining a 
specific behaviour for a specific driver.

For example, I don't think a tun interface goes down when there is no 
socket attached to it, still packets are just going to be blackhole'd in 
that case. No?

> 
>> I know it can be implemented in many other different ways..but I don't 
>> see a real problem with keeping this way.
> 
> At least routing protocols and network monitoring software will not be 
> happy to see a dead interface pretending that it's still running. 

They won't know that the interface is disconnected, they will possibly 
just see traffic being dropped.

> Generally speaking, saying that interface is running, when module knows 
> for sure that a packet can not be delivered is a user misguiding.

Or a feature, wanted by the user.

> 
>> A blackhole/firewall can still be added if the user prefers (and not 
>> use the persistent interface).
> 
> The solution with false-indication is not so reliable as it might look. 
> Interface shutdown, inability of a user-space application to start, 
> user-space application crash, user-space application restart, each of 
> them will void the trick. Ergo, blackhole/firewall must be employed by a 
> security concerned user. What makes the proposed feature odd.

Yeah, this is what other VPN clients call "kill switch".
Persist-tun is just one piece of the puzzle, yet important.

> 
> To summaries, I'm Ok if this change will be merged with a comment like 
> "For future study" or "To be done" or "To be implemented". But a comment 
> like "to prevent traffic leaking" or any other comment implying a 
> "breakthrough security feature" will have a big NACK from my side.

What if the comment redirects the user to --persist-tun option in order 
to clarify the context and the wanted behaviour?

Would that help?

> 
> -- 
> Sergey

Sergey Ryazanov Nov. 25, 2024, 2:26 a.m. UTC | #7

On 24.11.2024 00:52, Antonio Quartulli wrote:
> On 23/11/2024 23:25, Sergey Ryazanov wrote:
>> On 21.11.2024 23:17, Antonio Quartulli wrote:
>>> On 20/11/2024 23:56, Sergey Ryazanov wrote:
>>>> On 15.11.2024 16:13, Antonio Quartulli wrote:
>>>>> On 09/11/2024 02:11, Sergey Ryazanov wrote:
>>>>>> On 29.10.2024 12:47, Antonio Quartulli wrote:
>>>>>>> An ovpn interface will keep carrier always on and let the user
>>>>>>> decide when an interface should be considered disconnected.
>>>>>>>
>>>>>>> This way, even if an ovpn interface is not connected to any peer,
>>>>>>> it can still retain all IPs and routes and thus prevent any data
>>>>>>> leak.
>>>>>>>
>>>>>>> Signed-off-by: Antonio Quartulli <[e-mail]>
>>>>>>> Reviewed-by: Andrew Lunn <[e-mail]>
>>>>>>> ---
>>>>>>>   drivers/net/ovpn/main.c | 7 +++++++
>>>>>>>   1 file changed, 7 insertions(+)
>>>>>>>
>>>>>>> diff --git a/drivers/net/ovpn/main.c b/drivers/net/ovpn/main.c
>>>>>>> index 
>>>>>>> eead7677b8239eb3c48bb26ca95492d88512b8d4..eaa83a8662e4ac2c758201008268f9633643c0b6 100644
>>>>>>> --- a/drivers/net/ovpn/main.c
>>>>>>> +++ b/drivers/net/ovpn/main.c
>>>>>>> @@ -31,6 +31,13 @@ static void ovpn_struct_free(struct net_device 
>>>>>>> *net)
>>>>>>>   static int ovpn_net_open(struct net_device *dev)
>>>>>>>   {
>>>>>>> +    /* ovpn keeps the carrier always on to avoid losing IP or route
>>>>>>> +     * configuration upon disconnection. This way it can prevent 
>>>>>>> leaks
>>>>>>> +     * of traffic outside of the VPN tunnel.
>>>>>>> +     * The user may override this behaviour by tearing down the 
>>>>>>> interface
>>>>>>> +     * manually.
>>>>>>> +     */
>>>>>>> +    netif_carrier_on(dev);
>>>>>>
>>>>>> If a user cares about the traffic leaking, then he can create a 
>>>>>> blackhole route with huge metric:
>>>>>>
>>>>>> # ip route add blackhole default metric 10000
>>>>>>
>>>>>> Why the network interface should implicitly provide this 
>>>>>> functionality? And on another hand, how a routing daemon can learn 
>>>>>> a topology change without indication from the interface?
>>>>>
>>>>> This was discussed loooong ago with Andrew. Here my last response:
>>>>>
>>>>> https://lore.kernel.org/all/d896bbd8-2709-4834-a637- 
>>>>> [e-mail]/
>>>>
>>>> Thank you for sharing the link to the beginning of the conversation. 
>>>> Till the moment we have 3 topics regarding the operational state 
>>>> indication:
>>>> 1. possible absence of a conception of running state,
>>>> 2. influence on routing protocol implementations,
>>>> 3. traffic leaking.
>>>>
>>>> As for conception of the running state, it should exists for 
>>>> tunneling protocols with a state tracking. In this specific case, we 
>>>> can assume interface running when it has configured peer with keys. 
>>>> The protocol even has nice feature for the connection monitoring - 
>>>> keepalive.
>>>
>>> What about a device in MP mode? It doesn't make sense to turn the 
>>> carrier off when the MP node has no peers connected.
>>> At the same time I don't like having P2P and MP devices behaving 
>>> differently in this regard.
>>
>> MP with a single network interface is an endless headache. Indeed. On 
>> the other hand, penalizing P2P users just because protocol support MP 
>> doesn't look like a solution either.
> 
> On the upper side, with "iroutes" implemented using the system routing 
> table, routing protocols will be able to detect new routes only when the 
> related client has connected. (The same for the disconnection)
> 
> But this is a bit orthogonal compared to the oper state.

The patch has nothing common with the routes configuration. The main 
concern is forcing of the running state indication. And more 
specifically, the concern is the given justification for this activity.

>>> Therefore keeping the carrier on seemed the most logical way forward 
>>> (at least for now - we can still come back to this once we have 
>>> something smarter to implement).
>>
>> It was shown above how to distinguish between running and non-running 
>> cases.
>>
>> If an author doesn't want to implement operational state indication 
>> now, then I'm Ok with it. Not a big deal now. I just don't like the 
>> idea to promote the abuse of the running state indicator. Please see 
>> below.
>>
>>>> Routing protocols on one hand could benefit from the operational 
>>>> state indication. On another hand, hello/hold timer values mentioned 
>>>> in the documentation are comparable with default routing protocols 
>>>> timers. So, actual improvement is debatable.
>>>>
>>>> Regarding the traffic leading, as I mentioned before, the blackhole 
>>>> route or a firewall rule works better then implicit blackholing with 
>>>> a non-running interface.
>>>>
>>>> Long story short, I agree that we might not need a real operational 
>>>> state indication now. Still protecting from a traffic leaking is not 
>>>> good enough justification.
>>>
>>> Well, it's the so called "persistent interface" concept in VPNs: 
>>> leave everything as is, even if the connection is lost.
>>
>> It's called routing framework abuse. The IP router will choose the 
>> route and the egress interface not because this route is a good option 
>> to deliver a packet, but because someone trick it.
> 
> This is what the user wants.

Will be happy to see a study on user's preferences.

> OpenVPN (userspace) will tear down the P2P interface upon disconnection, 
> assuming the --persist-tun option was not specified by the user.
> 
> So the interface is gone in any case.
> 
> By keeping the netcarrier on we are just ensuring that, if the user 
> wanted persist-tun, the iface is not actually making decisions on its own.

Regarding a decision on its own. Ethernet interface going to the 
not-running state upon lost of carrier from a switch. It's hardly could 
be considered a decision of the interface. It's an indication of the fact.

Similarly, beeping of UPS is not its decision to make user's life 
miserable, it's the indication of the power line failure. I hope, at 
least we are both agree on that a UPS should indicate the line failure.

Back to the 'persist-tun' option. I checked the openvpn(8) man page. It 
gives a reasonable hints to use this option to avoid negative outcomes 
on internal openvpn process restart. E.g. in case of privilege dropping. 
It servers the same purpose as 'persist-key'. And there is no word 
regarding traffic leaking.

If somebody have decided that this option gives the funny side-effect 
and allows to cut the corners, then I cannot say anything but sorry.

> With a tun interface this can be done, now you want to basically drop 
> this feature that existed for long time and break existing setups.

Amicus Plato, sed magis amica veritas

Yes, I don't want to see this interface misbehaviour advertised as a 
security feature. I hope the previous email gives a detailed explanation 
why.

If it's going to break existing setup, then end-users can be supported 
with a changelog notice explaining how to properly address the risk of 
the traffic leaking.

>> At some circumstance, e.g. Android app, it could be the only way to 
>> prevent traffic leaking. But these special circumstances do not make 
>> solution generic and eligible for inclusion into the mainline code.
> 
> Why not? We are not changing the general rule, but just defining a 
> specific behaviour for a specific driver.

Yeah. This patch is not changing the general rule. The patch breaks it 
and the comment in the code makes proud of it. Looks like an old joke 
that documented bug become a feature.

 From a system administrator or a firmware developer perspective, the 
proposed behaviour will look like inconsistency comparing to other 
interface types. And this inconsistency requires to be addressed with 
special configuration or a dedicated script in a worst case. And I 
cannot see justified reason to make their life harder.

> For example, I don't think a tun interface goes down when there is no 
> socket attached to it, still packets are just going to be blackhole'd in 
> that case. No?

Nope. Tun interface indeed will go into the non-running state on the 
detach event. Moreover, the tun module supports running/non-running 
indication change upon a command from userspace. But not every userspace 
application feel a desire to implement it.

>>> I know it can be implemented in many other different ways..but I 
>>> don't see a real problem with keeping this way.
>>
>> At least routing protocols and network monitoring software will not be 
>> happy to see a dead interface pretending that it's still running. 
> 
> They won't know that the interface is disconnected, they will possibly 
> just see traffic being dropped.

Packet loss detection is quite complex operation. So yes, they are 
indeed monitoring the interface operational state to warn operator as 
soon as possible and take some automatic actions if we are talking about 
routing protocols. Some sophisticated monitoring systems even capable to 
generate events like 'link unstable' with higher severity if they see 
interface operational state flapping in a short period of time.

So yeah, for these kinds of systems, proper operational state indication 
is essential.

>> Generally speaking, saying that interface is running, when module 
>> knows for sure that a packet can not be delivered is a user misguiding.
> 
> Or a feature, wanted by the user.
> 
>>> A blackhole/firewall can still be added if the user prefers (and not 
>>> use the persistent interface).
>>
>> The solution with false-indication is not so reliable as it might 
>> look. Interface shutdown, inability of a user-space application to 
>> start, user-space application crash, user-space application restart, 
>> each of them will void the trick. Ergo, blackhole/firewall must be 
>> employed by a security concerned user. What makes the proposed feature 
>> odd.
> 
> Yeah, this is what other VPN clients call "kill switch".
> Persist-tun is just one piece of the puzzle, yet important.
> 
>>
>> To summaries, I'm Ok if this change will be merged with a comment like 
>> "For future study" or "To be done" or "To be implemented". But a 
>> comment like "to prevent traffic leaking" or any other comment 
>> implying a "breakthrough security feature" will have a big NACK from 
>> my side.
> 
> What if the comment redirects the user to --persist-tun option in order 
> to clarify the context and the wanted behaviour?
> 
> Would that help?

Nope. As it was mentioned above, the are no indication that 
'persist-tun' is a 'security' feature even in the current openvpn 
documentation.

If the openvpn developers want to keep implementation bug-to-bug 
compatible, then feel free to configure the blackhole route on behalf of 
end-user by means of the userspace daemon. Nobody will mind.

--
Sergey

Antonio Quartulli Nov. 25, 2024, 1:07 p.m. UTC | #8

On 25/11/2024 03:26, Sergey Ryazanov wrote:
>> OpenVPN (userspace) will tear down the P2P interface upon 
>> disconnection, assuming the --persist-tun option was not specified by 
>> the user.
>>
>> So the interface is gone in any case.
>>
>> By keeping the netcarrier on we are just ensuring that, if the user 
>> wanted persist-tun, the iface is not actually making decisions on its 
>> own.
> 
> Regarding a decision on its own. Ethernet interface going to the not- 
> running state upon lost of carrier from a switch. It's hardly could be 
> considered a decision of the interface. It's an indication of the fact.
> 
> Similarly, beeping of UPS is not its decision to make user's life 
> miserable, it's the indication of the power line failure. I hope, at 
> least we are both agree on that a UPS should indicate the line failure.

The answer is always "it depends".

> 
> Back to the 'persist-tun' option. I checked the openvpn(8) man page. It 
> gives a reasonable hints to use this option to avoid negative outcomes 
> on internal openvpn process restart. E.g. in case of privilege dropping. 
> It servers the same purpose as 'persist-key'. And there is no word 
> regarding traffic leaking.

FTR, here is the text in the manpage:

        --persist-tun
               Don't close and reopen TUN/TAP device or run up/down 
scripts across SIGUSR1 or --ping-restart restarts.

               SIGUSR1 is a restart signal similar to SIGHUP, but which 
offers finer-grained control over reset options.


SIGUSR1 is a session reconnection, not a process restart.
The manpage just indicates what happens at the low level when this 
option is provided.

The next question is: what is this useful for? Many things, among those 
there is the fact the interface will retain its configuration (i.e. IPs, 
routes, etc).

> 
> If somebody have decided that this option gives the funny side-effect 
> and allows to cut the corners, then I cannot say anything but sorry.
> 

Well, OpenVPN is more than 20 years old.
If a given API allows a specific user behaviour and had done so for 
those many years, changing it is still a user breakage. Not much we can do.

>> With a tun interface this can be done, now you want to basically drop 
>> this feature that existed for long time and break existing setups.
> 
> Amicus Plato, sed magis amica veritas
> 
> Yes, I don't want to see this interface misbehaviour advertised as a 
> security feature. I hope the previous email gives a detailed explanation 
> why.

Let's forget about the traffic leak mention and the "security feature". 
That comment was probably written in the middle of the night and I agree 
it gives a false sense or what is happening.

> 
> If it's going to break existing setup, then end-users can be supported 
> with a changelog notice explaining how to properly address the risk of 
> the traffic leaking.

Nope, we can't just break existing user setups.

> 
>>> At some circumstance, e.g. Android app, it could be the only way to 
>>> prevent traffic leaking. But these special circumstances do not make 
>>> solution generic and eligible for inclusion into the mainline code.
>>
>> Why not? We are not changing the general rule, but just defining a 
>> specific behaviour for a specific driver.
> 
> Yeah. This patch is not changing the general rule. The patch breaks it 
> and the comment in the code makes proud of it. Looks like an old joke 
> that documented bug become a feature.

Like I said above, let's make the comment meaningful for the expected 
goal: implement persist-tun while leaving userspace the chance to decide 
what to do.

> 
>  From a system administrator or a firmware developer perspective, the 
> proposed behaviour will look like inconsistency comparing to other 
> interface types. And this inconsistency requires to be addressed with 
> special configuration or a dedicated script in a worst case. And I 
> cannot see justified reason to make their life harder.

You can configure openvpn to bring the interface down when the 
connection is lost. Why do you say it requires extra scripting and such?

> 
>> For example, I don't think a tun interface goes down when there is no 
>> socket attached to it, still packets are just going to be blackhole'd 
>> in that case. No?
> 
> Nope. Tun interface indeed will go into the non-running state on the 
> detach event. Moreover, the tun module supports running/non-running 
> indication change upon a command from userspace. But not every userspace 
> application feel a desire to implement it.

With 'ovpn' we basically want a similar effect: let userspace decide 
what to do depending on the configuration.

> 
>>>> I know it can be implemented in many other different ways..but I 
>>>> don't see a real problem with keeping this way.
>>>
>>> At least routing protocols and network monitoring software will not 
>>> be happy to see a dead interface pretending that it's still running. 
>>
>> They won't know that the interface is disconnected, they will possibly 
>> just see traffic being dropped.
> 
> Packet loss detection is quite complex operation. So yes, they are 
> indeed monitoring the interface operational state to warn operator as 
> soon as possible and take some automatic actions if we are talking about 
> routing protocols. Some sophisticated monitoring systems even capable to 
> generate events like 'link unstable' with higher severity if they see 
> interface operational state flapping in a short period of time.
> 
> So yeah, for these kinds of systems, proper operational state indication 
> is essential.

Again, if the user has not explicitly allowed the persistent behaviour, 
the interface will be brought down when a disconnection happens.
But if the user/administrator *wants* to avoid that, he has needs a 
chance to do that.

Otherwise people that needs this behaviour will just have to stick to 
using tun and the full userspace implementation.

> 
>>> Generally speaking, saying that interface is running, when module 
>>> knows for sure that a packet can not be delivered is a user misguiding.
>>
>> Or a feature, wanted by the user.
>>
>>>> A blackhole/firewall can still be added if the user prefers (and not 
>>>> use the persistent interface).
>>>
>>> The solution with false-indication is not so reliable as it might 
>>> look. Interface shutdown, inability of a user-space application to 
>>> start, user-space application crash, user-space application restart, 
>>> each of them will void the trick. Ergo, blackhole/firewall must be 
>>> employed by a security concerned user. What makes the proposed 
>>> feature odd.
>>
>> Yeah, this is what other VPN clients call "kill switch".
>> Persist-tun is just one piece of the puzzle, yet important.
>>
>>>
>>> To summaries, I'm Ok if this change will be merged with a comment 
>>> like "For future study" or "To be done" or "To be implemented". But a 
>>> comment like "to prevent traffic leaking" or any other comment 
>>> implying a "breakthrough security feature" will have a big NACK from 
>>> my side.
>>
>> What if the comment redirects the user to --persist-tun option in 
>> order to clarify the context and the wanted behaviour?
>>
>> Would that help?
> 
> Nope. As it was mentioned above, the are no indication that 'persist- 
> tun' is a 'security' feature even in the current openvpn documentation.
> 

Like I mentioned above, I agree we should get rid of that sentence.
The security feature must be implemented by means of extra tools, just 
the interface staying up is not enough.

> If the openvpn developers want to keep implementation bug-to-bug 
> compatible, then feel free to configure the blackhole route on behalf of 
> end-user by means of the userspace daemon. Nobody will mind.

bug-to-bug compatible? What do you mean?
Having userspace configure a blackhole route is something that can be 
considered by whoeever decides to implement the "kill switch" feature.

OpenVPN does not. It just implements --persist-tun.

So all in all, the conclusion is that in this case it's usersapce to 
decide when the interface should go up and down, depending on the 
configuration. I'd like to keep it as it is to avoid the ovpn interface 
to make decisions on its own.

I can spell this out in the comment (I think it definitely makes sense), 
to clarify that the netcarrier is expected to be driven by userspace 
(where the control plane is) rather than having the device make 
decisions without having the full picture.

What do you think?

Regards,

Sergey Ryazanov Nov. 25, 2024, 9:32 p.m. UTC | #9

On 25.11.2024 15:07, Antonio Quartulli wrote:
> On 25/11/2024 03:26, Sergey Ryazanov wrote:
>>> OpenVPN (userspace) will tear down the P2P interface upon 
>>> disconnection, assuming the --persist-tun option was not specified by 
>>> the user.
>>>
>>> So the interface is gone in any case.
>>>
>>> By keeping the netcarrier on we are just ensuring that, if the user 
>>> wanted persist-tun, the iface is not actually making decisions on its 
>>> own.
>>
>> Regarding a decision on its own. Ethernet interface going to the not- 
>> running state upon lost of carrier from a switch. It's hardly could be 
>> considered a decision of the interface. It's an indication of the fact.
>>
>> Similarly, beeping of UPS is not its decision to make user's life 
>> miserable, it's the indication of the power line failure. I hope, at 
>> least we are both agree on that a UPS should indicate the line failure.
> 
> The answer is always "it depends".
> 
>> Back to the 'persist-tun' option. I checked the openvpn(8) man page. 
>> It gives a reasonable hints to use this option to avoid negative 
>> outcomes on internal openvpn process restart. E.g. in case of 
>> privilege dropping. It servers the same purpose as 'persist-key'. And 
>> there is no word regarding traffic leaking.
> 
> FTR, here is the text in the manpage:
> 
>         --persist-tun
>                Don't close and reopen TUN/TAP device or run up/down 
> scripts across SIGUSR1 or --ping-restart restarts.
> 
>                SIGUSR1 is a restart signal similar to SIGHUP, but which 
> offers finer-grained control over reset options.
> 
> 
> SIGUSR1 is a session reconnection, not a process restart.
> The manpage just indicates what happens at the low level when this 
> option is provided.

Still no mentions of the traffic leaking prevention. Is it?

> The next question is: what is this useful for? Many things, among those 
> there is the fact the interface will retain its configuration (i.e. IPs, 
> routes, etc).

This is unrelated to the correct operational state indication. Addresses 
and routes are not reset in case of interface going to non-running state.

>> If somebody have decided that this option gives the funny side-effect 
>> and allows to cut the corners, then I cannot say anything but sorry.
> 
> Well, OpenVPN is more than 20 years old.

More than 20 years of misguiding users has been duly noted :)

Should I mention that RFC 1066 containing ifOperStatus definition was 
issues 12 years before OpenVPN? And than it was updated with multiple 
clarifications.

> If a given API allows a specific user behaviour and had done so for 
> those many years, changing it is still a user breakage. Not much we can do.
> 
>>> With a tun interface this can be done, now you want to basically drop 
>>> this feature that existed for long time and break existing setups.
>>
>> Amicus Plato, sed magis amica veritas
>>
>> Yes, I don't want to see this interface misbehaviour advertised as a 
>> security feature. I hope the previous email gives a detailed 
>> explanation why.
> 
> Let's forget about the traffic leak mention and the "security feature". 
> That comment was probably written in the middle of the night and I agree 
> it gives a false sense or what is happening.
> 
>> If it's going to break existing setup, then end-users can be supported 
>> with a changelog notice explaining how to properly address the risk of 
>> the traffic leaking.
> 
> Nope, we can't just break existing user setups.
> 
>>>> At some circumstance, e.g. Android app, it could be the only way to 
>>>> prevent traffic leaking. But these special circumstances do not make 
>>>> solution generic and eligible for inclusion into the mainline code.
>>>
>>> Why not? We are not changing the general rule, but just defining a 
>>> specific behaviour for a specific driver.
>>
>> Yeah. This patch is not changing the general rule. The patch breaks it 
>> and the comment in the code makes proud of it. Looks like an old joke 
>> that documented bug become a feature.
> 
> Like I said above, let's make the comment meaningful for the expected 
> goal: implement persist-tun while leaving userspace the chance to decide 
> what to do.
> 
>>
>>  From a system administrator or a firmware developer perspective, the 
>> proposed behaviour will look like inconsistency comparing to other 
>> interface types. And this inconsistency requires to be addressed with 
>> special configuration or a dedicated script in a worst case. And I 
>> cannot see justified reason to make their life harder.
> 
> You can configure openvpn to bring the interface down when the 
> connection is lost. Why do you say it requires extra scripting and such?

Being administratively down and being operationally down are different 
states.

>>> For example, I don't think a tun interface goes down when there is no 
>>> socket attached to it, still packets are just going to be blackhole'd 
>>> in that case. No?
>>
>> Nope. Tun interface indeed will go into the non-running state on the 
>> detach event. Moreover, the tun module supports running/non-running 
>> indication change upon a command from userspace. But not every 
>> userspace application feel a desire to implement it.
> 
> With 'ovpn' we basically want a similar effect: let userspace decide 
> what to do depending on the configuration.
> 
>>
>>>>> I know it can be implemented in many other different ways..but I 
>>>>> don't see a real problem with keeping this way.
>>>>
>>>> At least routing protocols and network monitoring software will not 
>>>> be happy to see a dead interface pretending that it's still running. 
>>>
>>> They won't know that the interface is disconnected, they will 
>>> possibly just see traffic being dropped.
>>
>> Packet loss detection is quite complex operation. So yes, they are 
>> indeed monitoring the interface operational state to warn operator as 
>> soon as possible and take some automatic actions if we are talking 
>> about routing protocols. Some sophisticated monitoring systems even 
>> capable to generate events like 'link unstable' with higher severity 
>> if they see interface operational state flapping in a short period of 
>> time.
>>
>> So yeah, for these kinds of systems, proper operational state 
>> indication is essential.
> 
> Again, if the user has not explicitly allowed the persistent behaviour, 
> the interface will be brought down when a disconnection happens.
> But if the user/administrator *wants* to avoid that, he has needs a 
> chance to do that.
> 
> Otherwise people that needs this behaviour will just have to stick to 
> using tun and the full userspace implementation.
> 
>>
>>>> Generally speaking, saying that interface is running, when module 
>>>> knows for sure that a packet can not be delivered is a user misguiding.
>>>
>>> Or a feature, wanted by the user.
>>>
>>>>> A blackhole/firewall can still be added if the user prefers (and 
>>>>> not use the persistent interface).
>>>>
>>>> The solution with false-indication is not so reliable as it might 
>>>> look. Interface shutdown, inability of a user-space application to 
>>>> start, user-space application crash, user-space application restart, 
>>>> each of them will void the trick. Ergo, blackhole/firewall must be 
>>>> employed by a security concerned user. What makes the proposed 
>>>> feature odd.
>>>
>>> Yeah, this is what other VPN clients call "kill switch".
>>> Persist-tun is just one piece of the puzzle, yet important.
>>>
>>>>
>>>> To summaries, I'm Ok if this change will be merged with a comment 
>>>> like "For future study" or "To be done" or "To be implemented". But 
>>>> a comment like "to prevent traffic leaking" or any other comment 
>>>> implying a "breakthrough security feature" will have a big NACK from 
>>>> my side.
>>>
>>> What if the comment redirects the user to --persist-tun option in 
>>> order to clarify the context and the wanted behaviour?
>>>
>>> Would that help?
>>
>> Nope. As it was mentioned above, the are no indication that 'persist- 
>> tun' is a 'security' feature even in the current openvpn documentation.
>>
> 
> Like I mentioned above, I agree we should get rid of that sentence.
> The security feature must be implemented by means of extra tools, just 
> the interface staying up is not enough.
> 
>> If the openvpn developers want to keep implementation bug-to-bug 
>> compatible, then feel free to configure the blackhole route on behalf 
>> of end-user by means of the userspace daemon. Nobody will mind.
> 
> bug-to-bug compatible? What do you mean?

http://www.jargon.net/jargonfile/b/bug-compatible.html

With that difference, the local operational state indication does not 
break compatibility between hosts.

> Having userspace configure a blackhole route is something that can be 
> considered by whoeever decides to implement the "kill switch" feature.
> 
> OpenVPN does not. It just implements --persist-tun.
> 
> So all in all, the conclusion is that in this case it's usersapce to 
> decide when the interface should go up and down, depending on the 
> configuration. I'd like to keep it as it is to avoid the ovpn interface 
> to make decisions on its own.
> 
> I can spell this out in the comment (I think it definitely makes sense), 
> to clarify that the netcarrier is expected to be driven by userspace 
> (where the control plane is) rather than having the device make 
> decisions without having the full picture.
> 
> What do you think?

It wasn't suggested to destroy the interface in case of interface 
becoming non-operational. I apologize if something I wrote earlier 
sounded like that. The interface existence stays unquestionable. It's 
going to be solid persistent.

Back to the proposed rephrasing. If the 'full picture' means forcing the 
running state indication even when the netdev is not capable to deliver 
packets, then it looks like an attempt to hide the control knob of the 
misguiding feature somewhere else.

And since the concept of on-purpose false indication is still here, many 
words regarding the control plane and a full picture do not sound good 
either.

--
Sergey

Antonio Quartulli Nov. 26, 2024, 8:17 a.m. UTC | #10

On 25/11/2024 22:32, Sergey Ryazanov wrote:
[...]
>> FTR, here is the text in the manpage:
>>
>>         --persist-tun
>>                Don't close and reopen TUN/TAP device or run up/down 
>> scripts across SIGUSR1 or --ping-restart restarts.
>>
>>                SIGUSR1 is a restart signal similar to SIGHUP, but 
>> which offers finer-grained control over reset options.
>>
>>
>> SIGUSR1 is a session reconnection, not a process restart.
>> The manpage just indicates what happens at the low level when this 
>> option is provided.
> 
> Still no mentions of the traffic leaking prevention. Is it?

Like I said, the manpage only mentions the low level bits.
I have already proposed a patch to further extend this text.

[...]
>> Having userspace configure a blackhole route is something that can be 
>> considered by whoeever decides to implement the "kill switch" feature.
>>
>> OpenVPN does not. It just implements --persist-tun.
>>
>> So all in all, the conclusion is that in this case it's usersapce to 
>> decide when the interface should go up and down, depending on the 
>> configuration. I'd like to keep it as it is to avoid the ovpn 
>> interface to make decisions on its own.
>>
>> I can spell this out in the comment (I think it definitely makes 
>> sense), to clarify that the netcarrier is expected to be driven by 
>> userspace (where the control plane is) rather than having the device 
>> make decisions without having the full picture.
>>
>> What do you think?
> 
> It wasn't suggested to destroy the interface in case of interface 
> becoming non-operational. I apologize if something I wrote earlier 
> sounded like that. The interface existence stays unquestionable. It's 
> going to be solid persistent.
> 
> Back to the proposed rephrasing. If the 'full picture' means forcing the 
> running state indication even when the netdev is not capable to deliver 
> packets, then it looks like an attempt to hide the control knob of the 
> misguiding feature somewhere else.
> 
> And since the concept of on-purpose false indication is still here, many 
> words regarding the control plane and a full picture do not sound good 
> either.

Can you please point out the code where other virtual drivers are doing 
what you are suggesting so I can have a look?

Wireguard is the closest module in terms of concept and I couldn't see 
anything like that. Neither in ipsec.
But I may have overlooked something.

Please let me know.

Regards,

Patch

diff --git a/drivers/net/ovpn/main.c b/drivers/net/ovpn/main.c
index eead7677b8239eb3c48bb26ca95492d88512b8d4..eaa83a8662e4ac2c758201008268f9633643c0b6 100644
--- a/drivers/net/ovpn/main.c
+++ b/drivers/net/ovpn/main.c
@@ -31,6 +31,13 @@  static void ovpn_struct_free(struct net_device *net)
 
 static int ovpn_net_open(struct net_device *dev)
 {
+	/* ovpn keeps the carrier always on to avoid losing IP or route
+	 * configuration upon disconnection. This way it can prevent leaks
+	 * of traffic outside of the VPN tunnel.
+	 * The user may override this behaviour by tearing down the interface
+	 * manually.
+	 */
+	netif_carrier_on(dev);
 	netif_tx_start_all_queues(dev);
 	return 0;
 }