Bug 255008 - Modification of the SoftEther VPN 5 (Developer Edition) rc script for initial configure TAP interface
Summary: Modification of the SoftEther VPN 5 (Developer Edition) rc script for initial...
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Koichiro Iwao
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-12 16:36 UTC by shrdlu19
Modified: 2021-07-11 08:13 UTC (History)
2 users (show)

See Also:
shrdlu19: maintainer-feedback?


Attachments
softether_server modified rc script (1.78 KB, application/x-shellscript)
2021-04-12 16:36 UTC, shrdlu19
no flags Details
A new modified softether_server startup script from May 20, 2021 (2.19 KB, text/plain)
2021-05-20 12:38 UTC, shrdlu19
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description shrdlu19 2021-04-12 16:36:52 UTC
Created attachment 224055 [details]
softether_server modified rc script

Hello

I experimented with SoftEther VPN 5 Developer Edition (https://www.freshports.org/security/softether5/), and tried configuring Local Bridge using a virtual TAP interface. I was able to start the server with these settings, but for normal operation I need to manually run ifconfig to configure the ip-address on the created virtual interface, and these settings disappear after OS reboot or server restart.
I tried to modify the script that starts the Softether vpn server to fix this flaw. This works fine for me. I want to invite you to take a look at the changes I made.

First, I added three additional configuration parameters to the /usr/local/etc/rc.d/softether_server script:

# modified by shrdlu - added config options
# - tap_iface - TAP interface name for ifconfig command
# - tap_addr - TAP interface IP address for ifconfig command,
#   may be in CIDR format (a.b.c.d/x) or IP-address with netmask
#   (a.b.c.d netmask e.f.g.h)
# - tap_idle - delay before run ifconfig command for setup IP address on TAP interface
#
softether_server_tap_iface=${softether_server_tap_iface:-"none"}
softether_server_tap_addr=${softether_server_tap_addr:-"127.0.0.2/32"}
softether_server_tap_idle=${softether_server_tap_Idle:-"5"}

Secondly, I have defined a command to run after softether_server starts:

# modified by shrdlu - added command, running after softether-server started
#
start_postcmd="${name}_postcmd"

And I wrote a function that configures the virtual TAP interface:

# modified by shrdlu - postcmd - running ifconfig after softether-server started
# with new configuration parameters
#
softether_server_postcmd()
{
        if [ "${softether_server_tap_iface}" != none ]; then
                echo "Waiting ${softether_server_tap_idle} sec to create TAP interface"
                sleep ${softether_server_tap_idle}
                ifconfig ${softether_server_tap_iface} inet ${softether_server_tap_addr}
        fi
}

If people find these modifications correct and useful, then it might be worth checking out and including them in one of the next versions of the port. It is possible that some corrections need to be made. 

I have attached the my modified script to this report.
Comment 1 shrdlu19 2021-05-20 12:38:02 UTC
Created attachment 225120 [details]
A new modified softether_server startup script from May 20, 2021
Comment 2 shrdlu19 2021-05-20 12:38:44 UTC
After a while, I needed to create additional TAP interfaces, for which I had to rework the script again... perhaps this is not the best solution, but in any case it is more universal.

I removed the "softether_server_tap_iface" parameter and replaced it with
the "softether_server_tap_ifaces" parameter - it contains a list of TAP interface names for the ifconfig command
I also removed the "softether_server_tap_addr" parameter. Instead, the "softether_server_if _ <TAP interface name>" parameters should be specified in the rc.conf file in accordance with those listed in the "softether_server_tap_ifaces" list

This is how it looks now in my rc.conf:

softether_server_enable = "YES"
softether_server_tap_ifaces = "tap_vpn0 tap_vpn1"
softether_server_if_tap_vpn0 = "192.168.1.1/24"
softether_server_if_tap_vpn1 = "192.168.10.1/24" 

Then i modified a function that configures the virtual TAP interfaces:

# modified by shrdlu - postcmd - running ifconfig after softether-server started
# with new configuration parameters
#
softether_server_postcmd()
{
        if [ "${softether_server_tap_ifaceS}" != none ]; then

                echo "Waiting ${softether_server_tap_idle} sec to create TAP interface"
                sleep ${softether_server_tap_idle}

                for if_name in $softether_server_tap_ifaces; do
                        ifvar="softether_server_if_${if_name}"
                        eval "ifcfg=\$$ifvar"
                        ifconfig $if_name inet $ifcfg
                done;
        fi

}

So... there are definitely not enough error checks here, maybe I'll add them in the future. 

I have attached the my new modified script to this message.
Comment 3 Koichiro Iwao freebsd_committer 2021-06-22 04:48:14 UTC
r(In reply to shrdlu19 from comment #2)
Recently, I've updated SoftEther VPN 5 to v5.02.0. I'm trying to applying your rc script.
Comment 4 shrdlu19 2021-06-22 06:49:37 UTC
(In reply to Koichiro Iwao from comment #3)

Yeah, i'm updated today... but i see the same old rc.d script after update.
Comment 5 shrdlu19 2021-07-02 10:05:24 UTC
In version 5.02 Build 9675 OpenVPN clone server function is broken!
Clients can't connect to udp port 1194.

VPN Server>ServerInfoGet
ServerInfoGet command - Get server information
Item                            |Value
--------------------------------+---------------------------------------------------------------------------------
Product Name                    |SoftEther VPN Server Developer Edition (64 bit) (Open Source)
Version                         |Version 5.02 Build 9675   (English)
Build                           |Compiled 2021/07/01 20:37:50 by nobody at FreeBSD:12:2:amd64-default-daily-job-06
Host Name                       |test.example.com
Server Type                     |Standalone Server
Type of Operating System        |BSD System
Product Name of Operating System|FreeBSD
Operating System Vendor         |FreeBSD
Operating System Version        |12.2-RELEASE-p7
Type of OS Kernel               |UNIX
Version of OS Kernel            |FreeBSD 12.2-RELEASE-p7 GENERIC
The command completed successfully.

VPN Server>OpenVpnGet
"OpenVpnGet": Command not found.
You can use the HELP command to view a list of the available commands.
VPN Server>

All OpenVPN commands are lost!

Also, in confuguration file is no one information about OpenVPN config!
Only TCP connection are work.
Comment 6 Koichiro Iwao freebsd_committer 2021-07-09 12:29:46 UTC
(In reply to shrdlu19 from comment #5)
It is not broken, search the upstream issue. And it is related to this rc script bug.
Comment 7 shrdlu19 2021-07-10 05:47:59 UTC
(In reply to Koichiro Iwao from comment #6)

Hmm... The issue https://github.com/SoftEtherVPN/SoftEtherVPN/issues/1388 and related partially matches the description of what is happening, but does not explain the disappearance of all control commands related to openvpn...

And what exactly is the bug on rc script?
Comment 8 Koichiro Iwao freebsd_committer 2021-07-11 03:30:11 UTC
(In reply to shrdlu19 from comment #7)
I meant "bug" is a specific topic on *Bug*zilla. What was the topic of this BUG? Modifying rc script, right? If you want to have a talk on other issue, you should raise a new one. Don't talk about more than one issue on a single Bugzilla bug.
Comment 9 Koichiro Iwao freebsd_committer 2021-07-11 03:33:11 UTC
(In reply to shrdlu19 from comment #7)
I think your NEW issue is about "OpenVpnGet" command is missing. Search the upstream issues, too. Anyway, raise the new issue if you want to continue talking about anything other than the original RC script issue.
Comment 10 shrdlu19 2021-07-11 08:13:48 UTC
(In reply to Koichiro Iwao from comment #9)

Mea culpa. You're right, i'm sorry.
But, probably, this problem has nothing to do with the freebsd port, so I will write about it on github, a bit later.