openvpn client not work #272

ciccio88fcrlab · 2019-05-04T22:50:32Z

Hi all, I was trying to use Lua RTSO on ESP32 by enabling open vpn client. I cannot finish the compilation phase. I can finish it by modifying some files that give me an error during the compilation phase, but the flashing stops.

Can someone help me? Have you already used open vpn clients ?
Thank you

mariocolosi · 2019-05-09T17:22:37Z

up

christiansicari · 2019-05-09T17:24:34Z

I'm following

Valerialukaj · 2019-05-09T17:25:02Z

I have the same problem Help me please

alecatalfamo · 2019-05-09T17:28:43Z

Same issue!

ciccio88fcrlab · 2019-05-09T21:52:07Z

Hi everyone, I have made some progress, I load the firmware, openvpn starts, but the connection on UDP is not stable, it falls constantly and stops. On TCP does not work, any ideas? Please help me!!!!!

the0ne · 2019-07-08T14:28:52Z

After several modifications I could build the OpenVPN client and do some testing.
I have added functionality to stop openvpn after starting it.

I have an OpenVPN server that I use since a long time, so that part is tested and working.
Output of starting net.service.openvpn.start() follows

/ > net.service.openvpn.start()
Mon Jul  8 14:02:14 2019 1  [SSL (mbed TLS)] built on Jul  8 2019
Mon Jul  8 14:02:14 2019 library versions: mbed TLS 2.13.1
Mon Jul  8 14:02:15 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]XXXREMOVEDXXX:1194
Mon Jul  8 14:02:15 2019 Socket Buffers: R=[0->0] S=[0->0]
Mon Jul  8 14:02:15 2019 UDP link local: (not bound)
Mon Jul  8 14:02:15 2019 UDP link remote: [AF_INET]XXXREMOVEDXXX:1194
Mon Jul  8 14:02:15 2019 TLS: Initial packet from [AF_INET]XXXREMOVEDXXX:1194, sid=XXXREMOVEDXXX
Mon Jul  8 14:02:15 2019 VERIFY OK: depth=1, C=XXXREMOVEDXXX, ST=XXXREMOVEDXXX, L=XXXREMOVEDXXX, O=XXXREMOVEDXXX, CN=XXXREMOVEDXXX, emailAddress=XXXREMOVEDXXX
Mon Jul  8 14:02:15 2019 Validating certificate key usage
Mon Jul  8 14:02:15 2019 VERIFY KU OK
Mon Jul  8 14:02:15 2019 Validating certificate extended key usage
Mon Jul  8 14:02:15 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mon Jul  8 14:02:15 2019 VERIFY EKU OK
Mon Jul  8 14:02:15 2019 VERIFY OK: depth=0, C=XXXREMOVEDXXX, ST=XXXREMOVEDXXX, L=XXXREMOVEDXXX, O=XXXREMOVEDXXX, CN=XXXREMOVEDXXX, emailAddress=XXXREMOVEDXXX
Mon Jul  8 14:02:17 2019 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1558'
Mon Jul  8 14:02:17 2019 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
Mon Jul  8 14:02:17 2019 Control Channel: TLSv1.2, cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384, 1024 bit key
Mon Jul  8 14:02:17 2019 [RT-AC66U] Peer Connection Initiated with [AF_INET]XXXREMOVEDXXX:1194
Mon Jul  8 14:02:18 2019 SENT CONTROL [RT-AC66U]: 'PUSH_REQUEST' (status=1)
Mon Jul  8 14:02:18 2019 PUSH: Received control message: 'PUSH_REPLY,route 10.0.0.0 255.255.255.0 vpn_gateway 500,dhcp-option DNS 10.0.0.1,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 15,ping-restart 60,ifconfig 10.8.0.2 255.255.255.0,peer-id 0'
Mon Jul  8 14:02:18 2019 OPTIONS IMPORT: timers and/or timeouts modified
Mon Jul  8 14:02:18 2019 OPTIONS IMPORT: --ifconfig/up options modified
Mon Jul  8 14:02:18 2019 OPTIONS IMPORT: route options modified
Mon Jul  8 14:02:18 2019 OPTIONS IMPORT: route-related options modified
Mon Jul  8 14:02:18 2019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Jul  8 14:02:18 2019 OPTIONS IMPORT: peer-id set
Mon Jul  8 14:02:18 2019 OPTIONS IMPORT: adjusting link_mtu to 1624
Mon Jul  8 14:02:18 2019 Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Jul  8 14:02:18 2019 Outgoing Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jul  8 14:02:18 2019 Incoming Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Mon Jul  8 14:02:18 2019 Incoming Data Channel: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jul  8 14:02:18 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mon Jul  8 14:02:18 2019 Initialization Sequence Completed

There's several issues that I see:

Linking is NOT possible if CONFIG_LUA_RTOS_LUA_USE_SOCKET is enabled as this also defines 'socket_bind' (fixed with below PR)
Linking is NOT possible if CONFIG_LUA_RTOS_USE_SSH_SERVER is enabled (fixed with below PR)

The connection is re-built every few minutes

Mon Jul  8 14:11:24 2019 [RT-AC66U] Inactivity timeout (--ping-restart), restarting
Mon Jul  8 14:11:24 2019 Closing TUN/TAP interface
Mon Jul  8 14:11:24 2019 SIGUSR1[soft,ping-restart] received, process restarting
Mon Jul  8 14:11:24 2019 Restart pause, 5 second(s)

Which is probably normal.

The server seems to send us information about a local network interface we should maintain for the vpn-connection but net.stat() does not list this interface.
I can ping the local vpn endpoint 10.8.0.2 but not the remote vpn endpoint 10.8.0.1 nor that server's "normal" internal network address 10.0.0.1 or it's external IP-address.
The vpn-connection is not used by the system when using curl or plain socket requests.

@jolivepetrus I guess that's expected as you documented this in 707d754:

PUSHED routes from VPN server are ignored, so Lua RTOS only can access to the same VPN subnetwork. For example, if Lua RTOS has assigned the IP 10.8.50.25/24 it only can access to the 10.8.50.0/24 network.

the0ne · 2019-07-08T15:05:53Z

With #281 it's now possible to keep CONFIG_LUA_RTOS_LUA_USE_SOCKET enabled.
Also it's possible now to stop OpenVPN (which can take quite a while, see the PR) and to re-start it.
All notes and limitations of 707d754 regarding this experimental OpenVPN component still apply.

the0ne · 2019-07-08T15:09:37Z

Btw: Please be aware that the OpenVPN client consumes a huge amount of memory...

-------------------------------------------------------------------------------------------------------------------------
           |        |                  |        |        CPU        |            STACK               |        HEAP       
THID       | TYPE   | NAME             | STATUS | CORE   PRIO     % |   SIZE     FREE     USED       |  BLOCKS    TOTAL  
-------------------------------------------------------------------------------------------------------------------------
1073469208   lua      lua_main           run         0     20     0    10240     5948     4292 ( 41%)      473    48304  
1073518180   thread   openvpn            run         0     20     6     8192     1720     6472 ( 79%)      369    94344  
         0   task     IDLE0                          0      0    88     1024      408      616 ( 60%)        0        0  
         0   task     Tmr Svc                        0      1     0     2048     1644      404 ( 19%)        0        0  
         0   task     esp_timer                      0     22     0     4096     3388      708 ( 17%)       16     2264  
         0   task     eventTask                      0     20     0     8192     7284      908 ( 11%)        7      364  
         0   task     ipc0                           0     24     0     1024      532      492 ( 48%)       12     7060  
         0   task     signal                         0     21     0      768      320      448 ( 58%)        0        0  
         0   task     tiT                            0     18     0     2560     1156     1404 ( 54%)       25     5256  
         0   task     tun                            0     23     0     1024      404      620 ( 60%)        0        0  
         0   task     tun                            0     23     0     1024      408      616 ( 60%)        0        0  
         0   task     tun                            0     23     0     1024      404      620 ( 60%)        0        0  
         0   task     uart                           0     21     0      768      328      440 ( 57%)        0        0  
         0   task     wifi                           0     23     1     3072     1056     2016 ( 65%)       36    20112  
         0   task     IDLE1                          1      0    97     1024      584      440 ( 42%)        0        0  
         0   task     ipc1                           1     24     0     1024      484      540 ( 52%)        1       12  
         0   heap     0x3ffbeb18                     0      0     0        0        0        0 (  0%)       63    21380  
         0   heap     0x3ffc9608                     0      0     0        0        0        0 (  0%)        9      648  
         0   heap     root                           0      0     0        0        0        0 (  0%)        6     4832  
/examples/lua > os.stats()
Free mem: 68584
Free mem min: 48568
Free heap  8bit: 68584
Free heap 32bit: 125616
/examples/lua >

the0ne · 2019-07-09T07:44:32Z

make sure you also apply #282 which fixes some memory leaks that occur when the client re-connects to the server - which can happen more often than you might think

the0ne · 2019-07-09T09:27:04Z

also apply #283 which fixes a crash when reconnecting
now openvpn looks pretty stable.

but it's still losing memory:
at 09:08:10 (after start) it's using a heap of 93560 bytes
at 09:11:04 (after auto-restarting due to Inactivity timeout) it's using a heap of 94204 bytes
at 09:13:58 (after auto-restarting due to Inactivity timeout) I didn't check the heap
at 09:16:51 (after auto-restarting due to Inactivity timeout) it's using a heap of 95468 bytes after restarting due to Inactivity timeout
at 09:19:45 (after auto-restarting due to Inactivity timeout) it's crashing the esp32 with ESP_ERR_NO_MEM in function vfs_tun_register while calling esp_vfs_register

this means still about 640 bytes are lost on each auto-reconnect

the0ne · 2019-07-09T18:53:16Z

the small memory "leaks" seem come from the fact that openvpn, when auto-reconnecting keeps it's list of options and only adds the push-options - that it receives from the server each time it connects - to the end of that options-list. out of that options-list it assigns the values to it's pointers.

that is bad for us because it uses precious memory, but it seems that's not what takes 6k of memory each time but rather a few hundred bytes.

the fact that the missing heap memory is not shown might be caused by it being allocated by some other component that's used by the openvpn thread. looking into mbedtls might be a good guess.

after having stopped the openvpn thread - that had done one reconnect - when it's done with cleanup and has exited, there's 15 blocks of heap with a total of 7100 bytes that's lost.

ciccio88fcrlab · 2019-07-09T18:59:54Z

Thanks for your answers, I also thought the problem was this. Today I tried to do some tests, but I still can't load the firmware well. Do you think that using a sd card the vpv client works well?

the0ne · 2019-07-09T19:13:08Z

Hi @ciccio88fcrlab
What's your issue loading the firmware? I can simply flash it to some random esp32-coreboard, copy my client.conf, ca.crt, server.crt and server.key there and call net.service.openvpn.start()
How would an SD-card improve your issue?

ciccio88fcrlab · 2019-07-09T19:22:15Z

I flash the board but reboot. To load the firmare the first time, I had to make some changes to the code in some files, it wasn't enough to clone the project. I think a SD-card improve the situation if I can use it how an expansion of internal memory for the esp

ciccio88fcrlab · 2019-07-09T20:33:33Z

@the0ne This is my actual issue, solve the first error (change my python version in config menu):

the0ne · 2019-07-10T06:25:39Z

@ciccio88fcrlab
despite sd-cards are quite fast compared to spinning drives, they're slow compared to the ram built into the esp32. an sd-card cannot be used as ram. period.

the error looks like you enabled (external) spi ram in your menuconfig despite your hardware has none.
i guess setting back your sdkconfig file from CONFIG_SPIRAM_SUPPORT=y to CONFIG_SPIRAM_SUPPORT= should solve the above issue.

ciccio88fcrlab · 2019-07-10T10:13:40Z

Thanks so much, now I can flash the board. When I launch the vpn this happens:

the0ne · 2019-07-10T10:44:03Z

I would suggest turn the logging back to level 3 or max 8.
Also you should make sure that if you put some other device, e.g. your phone, into the same wifi (make sure to disable mobile data), that you are still able to connect to your vpn server. Only then it makes sense to further check why it doesn't work on the esp32.

ciccio88fcrlab · 2019-07-10T14:58:33Z

Ok, now I am able to create a tunnel, but the gw is not assigned:

Do you have an idea?

the0ne · 2019-07-11T06:03:48Z

First you should turn the logging up to 3. Then you should see a server PUSH and that PUSH should include the gw address.
If not, it might be as simple as your openvpn server being not configured right or not sending the gw for some other reason.

the0ne · 2019-07-11T06:10:28Z

Btw: the gw setting is also an issue in my testing scenario. But it seems different in your environment. Problematic place in my testing is around here: components/openvpn/src/openvpn/tun.c around line 548

        /*
         * If TAP-style interface, generate broadcast address.
         */
        if (!tun)
        {
            tt->broadcast = generate_ifconfig_broadcast_addr(tt->local, tt->remote_netmask);
        }

The broadcast (which is later used to set the gateway) is assigned the result of generate_ifconfig_broadcast_addr which only returns return local | ~netmask;

The interesting thing is that tun is false because the topology has the value 'subnet'.

So in my case broadcast (and later gw) is set to 10.8.0.255 instead of - what I would have expected - the server's vpn endpoint IP of 10.8.0.1.

But even in case that is correct it won't help anything to circumvent the known restriction** from 707d754:

PUSHED routes from VPN server are ignored, so Lua RTOS only can access to the same vpn subnetwork. For example, if Lua RTOS has assigned the IP 10.8.50.25/24 it only can access to the 10.8.50.0/24 network.

ciccio88fcrlab · 2019-07-11T21:57:19Z

@the0ne Thanks so much, I identified the problem, apparently there is a problem with address management, perhaps it also depends on the configuration of the vpn server. My open vpn server is https://github.com/kylemanna/docker-openvpn. I statically set the gw, the problem however is the tun, for me the tolopogy is 'net30', so I tried to adjust the code that you suggested me. Even if I set the gw statically, however, I can't ping the gw itself. Do you have any idea? Do you think the difficulties of reaching the subnet are related to memory problems in some way?

the0ne · 2019-07-12T06:30:43Z

It's probably the known restriction from 707d754:

PUSHED routes from VPN server are ignored, so Lua RTOS only can access to the same vpn subnetwork. For example, if Lua RTOS has assigned the IP 10.8.50.25/24 it only can access to the 10.8.50.0/24 network.

the0ne · 2019-12-31T11:17:46Z

@jolivepetrus do you think the following might be needed additionally to the existing patch?

diff --git a/components/tcpip_adapter/tcpip_adapter_lwip.c b/components/tcpip_adapter/tcpip_adapter_lwip.c
index 443fa54bb..a341ac4c0 100644
--- a/components/tcpip_adapter/tcpip_adapter_lwip.c
+++ b/components/tcpip_adapter/tcpip_adapter_lwip.c
@@ -153,10 +155,15 @@ static int tcpip_adapter_ipc_check(tcpip_adapter_api_msg_t *msg)
 
 static esp_err_t tcpip_adapter_update_default_netif(void)
 {
+    /* TUN runs on top of the others so we need to check for it FIRST */
-    if (netif_is_up(esp_netif[TCPIP_ADAPTER_IF_STA])) {
+    if (netif_is_up(esp_netif[TCPIP_ADAPTER_IF_TUN])) {
+        netif_set_default(esp_netif[TCPIP_ADAPTER_IF_TUN]);
+        ESP_LOGD(TAG, "TUN is the default netif now!");
+    } else if (netif_is_up(esp_netif[TCPIP_ADAPTER_IF_STA])) {
         netif_set_default(esp_netif[TCPIP_ADAPTER_IF_STA]);
     } else if (netif_is_up(esp_netif[TCPIP_ADAPTER_IF_ETH])) {
         netif_set_default(esp_netif[TCPIP_ADAPTER_IF_ETH]);

i believe this should be changed either way, looks like it was just forgotten:

@@ -428,7 +458,7 @@ esp_err_t tcpip_adapter_set_ip_info(tcpip_adapter_if_t tcpip_if, const tcpip_ada
 
     if (p_netif != NULL && netif_is_up(p_netif)) {
         netif_set_addr(p_netif, &ip_info->ip, &ip_info->netmask, &ip_info->gw);
-        if (tcpip_if == TCPIP_ADAPTER_IF_STA || tcpip_if == TCPIP_ADAPTER_IF_ETH) {
+        if (tcpip_if == TCPIP_ADAPTER_IF_STA || tcpip_if == TCPIP_ADAPTER_IF_ETH || tcpip_if == TCPIP_ADAPTER_IF_SPI_ETH || tcpip_if == TCPIP_ADAPTER_IF_TUN) {
             if (!(ip4_addr_isany_val(ip_info->ip) || ip4_addr_isany_val(ip_info->netmask) || ip4_addr_isany_val(ip_info->gw))) {
                 system_event_t evt;
                 memset(&evt, 0, sizeof(system_event_t));

I additionally stumbled upon that this might need to be enabled in lwipopts.h
#define IP_FORWARD 1
but during my tests it didn't solve the issue of not being able to get connection to any machine in the openvpn server network.

Might it be we need to use something similar to NAPT?

the0ne · 2020-01-03T16:32:11Z

added the above diffs as 66c87f1 resp. #328

@jolivepetrus what do you think about IP_FORWARD resp. NAPT?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

openvpn client not work #272

openvpn client not work #272

ciccio88fcrlab commented May 4, 2019 •

edited

mariocolosi commented May 9, 2019

christiansicari commented May 9, 2019

Valerialukaj commented May 9, 2019

alecatalfamo commented May 9, 2019

ciccio88fcrlab commented May 9, 2019

the0ne commented Jul 8, 2019 •

edited

the0ne commented Jul 8, 2019 •

edited

the0ne commented Jul 8, 2019

the0ne commented Jul 9, 2019

the0ne commented Jul 9, 2019

the0ne commented Jul 9, 2019

ciccio88fcrlab commented Jul 9, 2019

the0ne commented Jul 9, 2019

ciccio88fcrlab commented Jul 9, 2019

ciccio88fcrlab commented Jul 9, 2019

the0ne commented Jul 10, 2019 •

edited

ciccio88fcrlab commented Jul 10, 2019

the0ne commented Jul 10, 2019

ciccio88fcrlab commented Jul 10, 2019

the0ne commented Jul 11, 2019 •

edited

the0ne commented Jul 11, 2019 •

edited

ciccio88fcrlab commented Jul 11, 2019

the0ne commented Jul 12, 2019 •

edited

the0ne commented Dec 31, 2019

the0ne commented Jan 3, 2020 •

edited

openvpn client not work #272

openvpn client not work #272

Comments

ciccio88fcrlab commented May 4, 2019 • edited

mariocolosi commented May 9, 2019

christiansicari commented May 9, 2019

Valerialukaj commented May 9, 2019

alecatalfamo commented May 9, 2019

ciccio88fcrlab commented May 9, 2019

the0ne commented Jul 8, 2019 • edited

the0ne commented Jul 8, 2019 • edited

the0ne commented Jul 8, 2019

the0ne commented Jul 9, 2019

the0ne commented Jul 9, 2019

the0ne commented Jul 9, 2019

ciccio88fcrlab commented Jul 9, 2019

the0ne commented Jul 9, 2019

ciccio88fcrlab commented Jul 9, 2019

ciccio88fcrlab commented Jul 9, 2019

the0ne commented Jul 10, 2019 • edited

ciccio88fcrlab commented Jul 10, 2019

the0ne commented Jul 10, 2019

ciccio88fcrlab commented Jul 10, 2019

the0ne commented Jul 11, 2019 • edited

the0ne commented Jul 11, 2019 • edited

ciccio88fcrlab commented Jul 11, 2019

the0ne commented Jul 12, 2019 • edited

the0ne commented Dec 31, 2019

the0ne commented Jan 3, 2020 • edited

ciccio88fcrlab commented May 4, 2019 •

edited

the0ne commented Jul 8, 2019 •

edited

the0ne commented Jul 8, 2019 •

edited

the0ne commented Jul 10, 2019 •

edited

the0ne commented Jul 11, 2019 •

edited

the0ne commented Jul 11, 2019 •

edited

the0ne commented Jul 12, 2019 •

edited

the0ne commented Jan 3, 2020 •

edited