November 2, 2012 at 11:26 am #43483
I have 2 LAN connected by ZeroShell oVPN through 2 ISP. I add 2 routes on each box with different metrics to obtain failover channel between LANs.
If main oVPN disconnects, routes through this connection (with lower metric) on both boxes change status to “down” and all trafic go through 2nd oVPN connection (route with higher metric).
If main oVPN connection restored, “down” routes change status to “up” and traffic go through main oVPN connection again.
This works fine with ZeroShell 1.0b11 and b12, but not work in b13 and newer versions (I tried b13, b14, b16, 2.0RC1). In this versions when main oVPN disconnects, routes through this connection still active with status “up”! As result – no traffic between LANs.
I will have to upgrade hardware on ZeroShell boxes and install ZeroShell 2.0RC1 (because of new kernel), but this problem stops me.
Can anyone check/confirm this or explain the reasons? Is this ZeroShell problem?December 20, 2012 at 2:01 pm #52514
Sorry for my english.
Looks like I found the reason.
Zeroshell 1.0b12 uses OpenVPN 2.0.9
Newer versions uses OpenVPN >=2.1.1
In OpenVPN 2.1 changelog I found this:
Added additional method parameter to –script-security to preserve
backward compatibility with system() call semantics used in OpenVPN
2.1_rc8 and earlier. To preserve backward compatibility use:
script-security 3 system
OpenVPN 2.1 manual contains this:
–script-security level [method]
This directive offers policy-level control over OpenVPN’s usage of external programs and scripts. Lower level values are more restrictive, higher values are more permissive. Settings for level:
0 — Strictly no calling of external programs.
1 — (Default) Only call built-in executables such as ifconfig, ip, route, or netsh.
2 — Allow calling of built-in executables and user-defined scripts.
3 — Allow passwords to be passed to scripts via environmental variables (potentially unsafe).
The method parameter indicates how OpenVPN should call external commands and scripts. Settings for method:
execve — (default) Use execve() function on Unix family OSes and CreateProcess() on Windows.
system — Use system() function (deprecated and less safe since the external program command line is subject to shell expansion).
The –script-security option was introduced in OpenVPN 2.1_rc9. For configuration file compatibility with previous OpenVPN versions, use: –script-security 3 system
I decided to test my hypothesis and did the following:
1. After some investigation in Zeroshell I found script /root/kerbynet.cgi/vpn_ctl that starts OpenVPN connections. Command line contains param “–script-security 3”.
2. I make 2 Zeroshell boxes with 2.0RC2, connected by 2 physical LAN interfaces (primary and secondary), set up 2 OpenVPN connections (primary and secondary) through this LANs and make 2 routes on each box to other side with metrics 1 (primary LAN) and 10 (secondary LAN). Everything works fine. But when I physically disconnect primary LAN, route with metric 1 is still in routing table and there is no traffic betseen boxes, in Zeroshell web-interface it still have status “up”. When I connect primary LAN everything works fine again.
3. I edit /root/kerbynet.cgi/vpn_ctl script by change param to “–script-security 3 system” on each box.
4. After that I kill both OpenVPN process on each box.
5. Watchdog script /root/kerbynet.cgi/checkvpn starts them after few seconds by calling edited /root/kerbynet.cgi/vpn_ctl
6. I check “ps” on each box to make sure that both OpenVPN process contain “–script-security 3 system” param
7. I drop down primary OpenVPN connection by physically disconnect primary LAN cable
8. Route with metric 1 was removed from routing table automatically and change status to “down” in Zeroshell web-interface!!!
9. Routing table now contains only one active route to other side (route with metric 10) and traffic go through secondary LAN.
10. When I connect primary LAN, traffic go through primary LAN again, because route with metric 1 added to routing table after primary VPN connect and have status “up” in Zeroshell web-interface.
Thank you fo reading.
You must be logged in to reply to this topic.