[Ovmsdev] Request For Comments - Wireguard VPN

Tue Apr 25 15:28:19 HKT 2023

Hello Mark,

Thanks for the comments. I'll see how we can manage tunnels from the 
cli, should be doable.

Regarding the PR, here is one PR with only WireGuard support : 
https://github.com/llange/Open-Vehicle-Monitoring-System-3/pull/1 - it's 
just for review, as it is from my fork to itself.

For the WolfSSH / WolfSSL, I have some pending PRs on master, and I 
create new ones as soon as the previous ones are merged, as to not 
increase too much the burden on the reviewers.
They are here : 
https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse

(wolfssl will be a new one, not created yet, I'm waiting for the 
feedback on the wolfssh one - is a new submodule acceptable or not, or 
is it better to have a subtree, or a copy, ....)

Regards,

Le 25/04/2023 à 02:49, Mark Webb-Johnson a écrit :
> Really glad to see this, and thanks for working on it.
>
> I do think it would be useful to have many wireguard circuits 
> configurable.
>
> For my own use case, I would like to be able to bring up a wireguard 
> circuit purely from the command line (with no configuration set). This 
> is because I am frequently called in to help with 
> setup/configuration/diagnostic issues remotely, and having a full VPN 
> would be extremely useful for that. If I could just send a single 
> command to start the vpn back to me, then ssh into the module (or get 
> can bus data over tcp/ip, etc), it would help tremendously.
>
> Regarding the PR, can we split this into (a) for wolfssh/wolfssl as a 
> module, and (b) for wireguard support. At the moment, it is quite hard 
> to review with both in the same PR.
>
> Regards, Mark.
>
>> On 24 Apr 2023, at 5:35 PM, Ludovic LANGE <ll-ovmsdev at lange.nom.fr> 
>> wrote:
>>
>> Dear list,
>>
>> A few months ago I created 
>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 
>> to explore WireGuard VPN support ; which leaded me to add ESP-IDFv5 
>> support to OVMS.
>>
>> Now that this ESP-IDFv5 support is added (in my branch, and it is in 
>> the progress of getting included in master - with the help and the 
>> testing of everybody here), I've resumed my exploration of adding 
>> support for WireGuard VPN to OVMS.
>>
>> It's now ready for comments, you can now check:
>>
>>   * a new branch here
>>     https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/752-wireguard
>>   * a DRAFT PR here
>>     https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/882
>>
>> if you want to explore and test this VPN support for OVMS.
>>
>>
>> My own use case for this feature is :
>>
>>   * Security : I would like my module to be unreachable from the
>>     public Internet. This is a first step.
>>   * Practicality : I can reach my module with a single IP address /
>>     name that is part of my private network. SSH, Web, SCP, ... all
>>     work as if my module is local to my servers
>>   * Roaming : The idea is to have a single point of contact even if
>>     the module changes network, changes IP address, etc...
>>
>> Part of this feature set is already available with a combination of 
>> the OVMS Server (v2, v3) and the Hologram.io services, but I wanted 
>> to be independent of the mobile connexion provider, and also file 
>> transfer is important for my use case (SCP or other), as I'm often 
>> wanting to sync the content of the SD card over the network.
>>
>>
>> If you can have a look and give feedback (either here, or on the PR), 
>> especially on:
>>
>>   * The documentation : is it enough ? properly organized ? should it
>>     be split ? etc...
>>   * The command set
>>   * The configuration items : what's missing ? is the naming OK ?
>>   * Other features (should I introduced events ? metrics ?)
>>
>> Also if you have any feature request, please share.
>>
>> Limitations:
>>
>>   * Currently limited to 1 tunnel, but should work with multiple -
>>     it's just a question of arranging the configuration to support
>>     multiple instances
>>   * Roaming not tested yet (will report)
>>   * Compatibility with mobile network not tested yet (will need help
>>     on this)
>>   * I'm not really happy with the way I set the configuration items.
>>     I'd like to "hide" (write-only) the important bits (private key,
>>     shared key), but fear that it would clutter the config namespace
>>     - especially if I introduce multiple tunnels.
>>     Maybe one solution would be to have a rich configuration per
>>     tunnel (like a JSON / YAML), which would be a nightmare to edit
>>     by hand and would need support in the web interface.
>>   * Tunnel always active as soon as the configuration is correct. May
>>     be will need to add an enabled/disabled flag to the
>>     configuration, and/or an auto-start flag.
>>
>> Current status:
>>
>>   * Builds on GitHub actions (if you can to test, pre-compiled
>>     firmwares are available here for example:
>>     https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions/runs/4784405668
>>     - just download a Zip file (v5.0 or v5.0.1), and flash with a
>>     command-line like esptool.py --chip esp32 --port /dev/xxxx --baud
>>     921600 write_flash --compress --flash_mode "dio" --flash_freq
>>     "40m" --flash_size detect 0x10000 ovms3.bin )
>>   * Works on My Machine (tunnel is UP, SSH is working OK, HTTP is
>>     working OK, performances look OK. Ping time (ICMP) is comparable
>>     with or without tunnel)
>>
>>
>> Thanks for your comments.
>>
>> Regards,
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230425/e14d7f37/attachment.htm>