Send connman mailing list submissions to
connman@lists.01.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
connman-requ...@lists.01.org
You can reach the person managing the list at
connman-ow...@lists.01.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH 06/11] network: Adopt to new IPv6 disabled functionality of
ipconfig.c
(Jussi Laakkonen)
2. Re: [PATCH 08/11] provider: Toggle IPv6 on the transport of IPv4 VPN
connection
(Jussi Laakkonen)
3. Re: [PATCH 09/11] service: Change IPv6 support if split routing value
changes on IPv4 VPN
(Jussi Laakkonen)
----------------------------------------------------------------------
Date: Wed, 7 Apr 2021 10:51:07 +0300
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
Subject: Re: [PATCH 06/11] network: Adopt to new IPv6 disabled
functionality of ipconfig.c
To: Daniel Wagner <w...@monom.org>
Cc: connman@lists.01.org
Message-ID: <e821a4ee-c547-62b1-706d-30eda7c5f...@jolla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel,
On 4/6/21 9:28 PM, Daniel Wagner wrote:
> Hi Jussi,
>
> On Tue, Apr 06, 2021 at 04:21:04PM +0300, Jussi Laakkonen wrote:
>> I thought that the service can keep its IPv4 configuration.
>
> static void autoconf_ipv6_set(struct connman_network *network)
> {
> [...]
> service = connman_service_lookup_from_network(network);
> if (!service)
> return;
>
> ipconfig = __connman_service_get_ip6config(service);
> if (!ipconfig)
> return;
>
> __connman_ipconfig_enable(ipconfig); // a)
>
> __connman_ipconfig_enable_ipv6(ipconfig); // b)
>
>
> I am talking about this enable in a). If we bail out in b), shouldn't we
> undo a)? Anyway, I am confused why we have IPv4 code here. The function
> clearly talks about IPv6 only. After starring at it, I am completely
> lost.
>
> Thanks,
> Daniel
>
Ah yes, that but the a) is a dual-mode function. It does the changes
based on ipconfig->type and bails out if enable_ipv6() returns error so
I viewed it as unnecessary change then to have anything cleaned on that
a) part.
Might it just complicate things to check also here if IPv6 is
enabled/forced off for the ipconfig as in both functions,
__connman_ipconfig_enable() -> enable_ipv6() and
__connman_ipconfig_enable_ipv6() -> enable_ipv6() results in the same
situation.
I understood that the __connman_ipconfig_enable() simply prepares the
interface for the type that is about to be enabled, if possible. It
could bail out even in a) as well depending on the return value.
Cheers,
Jussi
------------------------------
Date: Wed, 7 Apr 2021 13:24:07 +0300
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
Subject: Re: [PATCH 08/11] provider: Toggle IPv6 on the transport of
IPv4 VPN connection
To: Daniel Wagner <w...@monom.org>
Cc: connman@lists.01.org
Message-ID: <131c0aed-7f07-04bf-8c9e-7aa359f4f...@jolla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Daniel,
On 4/6/21 9:42 PM, Daniel Wagner wrote:
> Hi Jussi,
>
> On Tue, Apr 06, 2021 at 04:44:00PM +0300, Jussi Laakkonen wrote:
>>> This disables IPv6 for all VPN tunnels not just for pure IPv4 VPNs. I
>>> think you need to check the ipconfig if IPv6 should be disabled. I have
>>> actually an IPv4/IPv6 VPN service to test ;)
>>>
>>
>> Oh I must have mistaken something then. I've always understood this that
>> each provider can be either IPv4 or IPv6 as the code suggests, and one
>> provider = one connection. Or did I now misread your comment..
>
> I think it depends what the VPN is able to do, that is if we are talking
> about network layer or transport layer. Mabye I understood you wrong. I
> assumed you were talking about an VPN which will only support IPv4. But
> that should not exclude a dual protocol VPN IMO. Probably I
> misunderstood your initial RFC.
>
I guess we both misunderstood. For the potential use of dual-mode VPNs,
even though the family is set as AF_INET I did include a check for the
VPNs ipconfig to simply use __connman_ipconfig_ipv6_is_enabled() and
bail out if the VPN has IPv6 enabled. Many of the VPN plugins are still
in IPv4 only mode and these do seem to get IPv6 disabled by default.
It is still a guess as I have no dual-stack VPN at my disposal but those
should have IPv6 enabled (disable_ipv6 0) -> IPv6 is not getting
disabled on such VPN.
>> Yeah, this is one of the things why I first sent the RFC. We do limit to
>> having only one connected VPN at a time so I wasn't able to test all
>> possible scenarios.
>
> And there is the resource problem. If the VPN server needs to maintain
> two session per user, admins will start to scream.
>
>> There is a check for split routing of the VPN, the
>> change is not done if the VPN is not going to be the default, i.e., split
>> routing is true. But I guess you weren't after this.
>
> My setup is actually a splitted IPv4/IPv6 VPN tunnel which is not the
> default route.
Well I guess this becomes a bit philosophical issue then. Which would be
the default action when running a IPv4 only VPN_1 on top of a VPN_2 that
supports dual stack. User might assume that all traffic goes over the
VPN_1, and nothing leaks to transport or any other without any
interaction, right? So it would be explicitly disabled if a security
feature is to be overridden.
But yeah, there apparently is a need to remove the family check.
>
>> I did confuse myself with this a multiple times already.. So instead of
>> relying to provider family there should be a check on which ipconfigs the
>> actual VPN service has enabled? I wasn't aware that it was possible to work
>> that way as I relied on the family setting. Well, I haven't had any VPNs
>> configured as dual-stack either.
>
> I hear you, the code is indeed difficult and confusing.
>
Yes, battling with the differences with our fork and upstream does not
help there. But maybe one day we get closer..
>> I guess that family for the provider should be somehow changed/extended to
>> support that as well.
>
> That is also my thinking, maybe instead adding a lot of magic code just
> add an explicit setting/config option if IPv6 should be enabled or not.
>
I guess I should file a new patch set, as that requires changes to
vpn/vpn-provider.c and plugins/vpn.c in addition to replacing the family
checks in src/provider.c as well as in the PATCH 09/11 src/service.c on
that split routing change part.
But in general, I'd prefer to keep the feature on by default, to disable
IPv6 when the non-split routed VPN becomes connected, i.e., ends up
being the default route and service.
Any other thoughts?
Cheers,
Jussi
------------------------------
Date: Wed, 7 Apr 2021 13:45:18 +0300
From: Jussi Laakkonen <jussi.laakko...@jolla.com>
Subject: Re: [PATCH 09/11] service: Change IPv6 support if split
routing value changes on IPv4 VPN
To: David Woodhouse <dw...@infradead.org>, connman@lists.01.org
Message-ID: <c9382d8c-84dd-1d9e-7c6a-a3e0d3efa...@jolla.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi David,
On 4/6/21 5:31 PM, David Woodhouse wrote:
> On Tue, 2021-04-06 at 17:00 +0300, Jussi Laakkonen wrote:
>> Hi David,
>>
>> Thanks for the feedback.
>>
>> On 4/6/21 12:17 PM, David Woodhouse wrote:
>>> On Tue, 2021-04-06 at 09:34 +0100, David Woodhouse wrote:
>>>> On Thu, 2021-04-01 at 17:46 +0300, Jussi Laakkonen wrote:
>>>>> Enable/disable IPv6 on VPNs transport when the split routing value
>>>>
>>>> is
>>>>> changed. This is important in both cases when a connected IPv4 VPN
>>>>
>>>> has
>>>>> the value changed as with split routing -> non-split routing IPv6
>>>>
>>>> should
>>>>> be disabled as well as non-split-routing -> split routed IPv6
>>>>
>>>> should be
>>>>> re-enabled.
>>>>
>>>> Not necessarily. In the Cisco AnyConnect protocol there's a separate
>>>> flag to indicate whether IPv6 should be blocked or not, even when the
>>>> VPN does take the default Legacy IP route.
>>>>
>>>> Surely this should be just part of the routing information that the
>>>> protocol-specific VPN provider itself passes back to ConnMan? It just
>>>> needs a way to request a default IPv6 'unreachable' route?
>>>>
>>>> Likewise, if a VPN is IPv6-only it *might* or might not want to add a
>>>> default Legacy IP 'unreachable' route.
>>>>
>>
>> I was really under the assumption that provider's family dictates which
>> of the IP-families can be used.
>
> Definitely not. The protocol family that used to connect to the VPN
> server is *entirely* orthogonal to the protocol families that the VPN
> might provide within that tunnel.
>
> Note that the protocol used for the connection might change from one
> connection to the next; depending on DNS round robin and network
> environment and many other things.
I guess you did not focus on the code then? IPv6 is getting disabled
only for the duration the particular VPN that is acting as a default
route, i.e., non-split routed, is connected. But only if the VPN does
explicitly set disable_ipv6 1 for the interface this feature kicks in.
When the VPN disconnects all interfaces will get IPv6 returned and
addresses are re-fetched.
In case split routing changes from non-split routed to split routed IPv6
is returned into use as well if it had been disabled in the first place
by following the disable_ipv6 setting.
>
>>>> Just expose that facility from core ConnMan and let the VPN providers
>>>> use it as they desire.
>>
>> I actually had this in mind as a next step to have a per provider option
>> to really control whether to disable IPv6 or not. Some amount of work
>> goes to that as well and I think OpenConnect and WireGuard plugins are
>> ones that are capable of both v4 and v6.
>>
>> What do you Daniel say, should I try to include that per provider option
>> here or work it as later, and perhaps amend the TODO on that part?
>
> I think you should *only* do the per-provider thing. Just give
> providers a way to request 'unreachable' routes on Legacy IP and/or
> IPv6 as part of their routing configuration, and that's all we want in
> the core.
I simply viewed this feature as an security improvement to protect the
user's traffic. One of the worst situations is that user's networking
conditions change without knowing (SIM upgrade, at least my mobile data
got IPv6 back in the day without any announcement) and user still
remains using the same VPN that has been always in use as the used
device didn't change. In this scenario without user's knowledge the DNS
server of the VPN can return AAAA records and when IPv6 is enabled on
the transport -> data leak.
Thus, in addition to most of the VPNs being IPv4 only, I'd regard this
as an opt-out feature rather an opt-in, just to simply protect the user.
If the VPN keeps IPv6 enabled then nothing is done. But yeah, if someone
just simply wants to override the feature it should be configurable on
provider level. Now, that needs to be a vpnd side feature communicated
and signaled to connmand, only OpenConnect and WireGuard seem to need
that opt-out feature. That OpenConnect plugin change to use the lib is
required as a basis to that then.
>
> Except... while we're at it, we should also have the facility to allow
> or deny access to the local subnet. Some VPN configurations permit it,
> some request that it be blocked. By default, I think we always allow it
> as an implicit "split exclude" but we shouldn't.
>
Sorry, no I cannot extend this work with any more features. It has taken
already too much time on our side to get this working at this level and
I'll soon need to move on to next tasks. Please add this to feature you
described to the TODO list so someone can then work on that later on.
Cheers,
Jussi
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- connman@lists.01.org
To unsubscribe send an email to connman-le...@lists.01.org
------------------------------
End of connman Digest, Vol 66, Issue 11
***************************************
