I have one Omnia (upgraded to OS 5) configured as an OpenVPN server and it works as it should.
The server is getting ready after each reboot, clients are able to connect regardless of its platform (android, windows, ubuntu Linux).
The problem is with the second Turris MOX, which is configured as an OpenVPN client. Last weekend I set the OpenVPN up and everything was working fine. I even tried ssh to the server-side and then back to my laptop currently at the client-side.
Then the power to the MOX was interrupted and when it was restored, both WAN and LAN interfaces are properly working but the VPN client gets not connected.
I am 40 km far away now, I can check it tomorrow (weekend again), but I really need it to reconnect always the power is applied and the wan network is ready.
I didn’t notice whether there is such a setting to make it permanent or not.
And yes, the power must be interrupted whenever the house (under construction) is abandoned.
Now I am at the installation place. I see that the client is connected (not sure if it was I tried to log in remotely), but there is routing problem.
I can ping lan addresses at the server side (192.168.1.0/24), but the other direction doesn’t work.
I tried to add a static route at the server side, pointing to the client side network (192.168.2.0/24) via the vpn gateway /(10.111.111.2), but it didn’t help.
I can see now, that this is not a bug, but a missing/wrong configuration. Unfortunately I already forgot the routing knowledge over the last ten years not doing it.
To enable openvpn autostart, ensure you have service enabled /etc/init.d/openvpn enable. Check UCI config /etc/config/openvpn if you have option enabled '1' for that openvpn-client setup. That should bring all enabled openvpn instances after bootup. In case you do not want autostart, you can use /etc/rc.local and you can add startup command there.
Actually there is no problem with autostart.
The problem was routing and now it’s only about the firewall setup as I started to see when I dove into the investigation.
I still don’t know how to set it correctly, but i did this test.
When i open port 22 for everyone at the client side iptables -I INPUT -p tcp --dport 22 -j ACCEPT
Then i’m able to make the ssh connection in the before broken direction.
I rather would like to close this thread, because I can’t see any benefit if we two are communicating single topic with each other in two languages in two threads.
I originally thought that in English there will be more interested people in this discussion, but no, no one’s interested except Maxmilian.