VPN unstable



I happen to have one vpn on version 13.2s0, with an unstable vpn and no apparent reason why it fails; the logs say it cannot reach
However, with my pc (in the same VLAN and subnet as the ewon) i can ping perfectly fine



Sorry for the delay, I just realized I had typed this earlier and didn’t hit send.

Looking at your settings, there are a couple things that pop out:

  • It doesn’t look like you have the correct time zone set. This can cause problems with the networking.
  • You are using a public subnet address on your LAN with IP addresses used by ISPs. It is possible for this to cause routing problems. Use instead of, for example.

Most of the errors are related to connecting on the WAN and the IO server. Check the WAN connection, that it is giving a good IP address and DNS settings and connection is good. Check IO server settings (separate issue - not related to VPN.)



Hi Kyle,

-We normally use UTC in all our machines
-Yes, since we deliver machines that are integrated in a customers network, the network inside the machine (not connected to customers lan), cannot contain any possible ip that is related to the customers network (so no 192.168.x.x and no 10.x.x.x).

  • The plc was not connected at that time so disregard the errors pertaining to the IO server…

It should still build up vpn connection right?


We have multiple ewon's and [u]**not one of the wire bound (ADSL) EWONS is stable**[/u] (13.0 - 13.2).

We need to get this fixed, this Ewon is also not stable on WAN… (same LAN config 50.50.50.x, 1 plc, 1 plc screen no connections to the internet).



The logs you just sent show the device (flexy 205 w/fw v13.0) consistently rebooting every 3 minutes and ten seconds starting on 1/3 at 20:40 (when logs start) until 1/4 at 09:39. What changed at that time? It rebooted once on the 5th due to power loss, but was running up until today with no errors other than one dns error at 10:30 at night.

Does the device have any extension cards or an SD card?

Have there been any recent changes to the BASIC scripts running? Is it possible to stop them and see if the performance improves so we can try to isolate the issue?



Nothing changed, the unit having this logs is running in an enclosure for weeks…
It has an own private ADSL internet connection.
It has no extension cars or SD card.

No changes in the Basic scripts, we switched it off
08/01/2019 08:31:41 1073779924 bidiproto-User connected biditr
08/01/2019 08:31:38 1073779925 bidiproto-All users disconnected biditr
08/01/2019 08:31:26 1073779924 bidiproto-User connected biditr
08/01/2019 08:31:18 1073771442 ovpn-OpenVPN process start wanmgt
08/01/2019 08:31:15 1073772969 wanmgt-Open WAN interface wanmgt
08/01/2019 08:31:10 1073772933 wanmgt-Restarting permanent WAN connection wanmgt
08/01/2019 08:31:09 1073768651 stdios-Configuration of IOServer (S73&400) main
08/01/2019 08:31:07 1073762140 Reboot reason: Unknown (power loss,…) wd
08/01/2019 08:31:06 -22602 System Booting, FWR: 13.0s0 (13.0), SN: 1840-0048-24 [EF0000] elog
08/01/2019 08:29:53 1073779924 bidiproto-User connected biditr
07/01/2019 14:20:49 1073779925 bidiproto-All users disconnected biditr
07/01/2019 14:20:19 1073779924 bidiproto-User connected biditr
07/01/2019 11:47:51 1073779925 bidiproto-All users disconnected biditr
07/01/2019 09:31:10 1073779924 bidiproto-User connected biditr
07/01/2019 08:20:14 1073779925 bidiproto-All users disconnected biditr
07/01/2019 07:25:20 1073763130 eftp-Close FTP session (User: resato) ftps
07/01/2019 07:25:18 1073763129 eftp-Open FTP session (User: resato) ftps
07/01/2019 07:24:44 1073763130 eftp-Close FTP session (User: resato) ftps
07/01/2019 07:24:44 1073763129 eftp-Open FTP session (User: resato) ftps
07/01/2019 07:19:04 1073779924 bidiproto-User connected biditr

It is technically impossible for a user to switch off power…(it is inside a locked cabinet).

Best regards,


HTTP requests timing out are causing the constant reboots. What do you have running other than the BASIC code sending out HTTP requests?



Good call,

We have nothing other than the basic code…
S7&400 import for the Siemens PLC…
Basic code was off last night…(it still rebooted though)…

What would be a possible solution, check if dns could be resolved before sending http post messages? In init, and when a connection loss occurs, let the watchdog reboot the ewon?


DNS resolves or ping response would be a good test. Occasionally we see problems when the BASIC code is looping and not making a connection, it’s overloading the system enough to prevent a connection. It could also be the application generating long duration output, so I would first try increasing the time of HTTP_REQTO like the article above states.

The fact that it rebooted last night when the code wasn’t running though may mean there’s something else going on. If I could get access to the eWON (via Teamviewer or temp credentials) today or at least a copy of the logs from last night that would be great.




I made an admin account for you:



Forgot to give you rights on the Ewon itself

Please remove sensitive info


thank you!


Looks like it’s been online for a few days now with no problems. I changed a couple settings which I hope will prevent it from going offline, but I didn’t want to turn the BASIC back on without checking with you first. I’m interested in what will happen when it starts up again.



Hi Kyle,

latest reboot was 8/1…
I am eager to learn what you changed
You can definitely activate the basic script

Best regards,


I just changed the HTTP_REQTO to give it more time and added a second DNS server because I noticed tehre were still a couple DNS errors in the logs.

I have been trying to connect to the eWON, but there are too many connections being used right now on the account.


I have logged out, it looks like it is stable…
Thus an unstable dns was the reason?


I hadn’t started the BASIC yet at that point, but I did about an hour ago and it rebooted once and then came back up and has been good since. I tried to download logs, but didn’t have permissions, no big deal. I doubt the DNS was the cause of all the problems, hoping the HTTP time out setting gets it back to being stable.


Backup (1).etar.gz (27.7 KB)

These are the ones through the webinterface, it is stable now…