Commit 9399f3
2025-02-11 11:49:52 Samuli Seppänen: -/-| /dev/null .. FAQ/325-openvpn-as-a--forking-tcp-server-which-can-service-multiple-clients-over-a-single-tcp-port.md | |
| @@ 0,0 1,92 @@ | |
| + | # OpenVPN as a Forking TCP Server Which Can Service Multiple Clients Over a Single TCP Port |
| + | |
| + | **WARNING: this article is very outdated and refers to obsolete version of OpenVPN. This article is kept here purely for historical reference.** |
| + | |
| + | See the OpenVPN 2.0 release notes. |
| + | |
| + | Also: |
| + | |
| + | Here at work, we wanted to implement a VPN solution for Roadwarriors who have to connect to the main office. OpenVPN looked like a nice solution, as it also works with Windows and can tunnel through an https proxy. |
| + | |
| + | One problem though, was the inability to use a constant port number on the server side. |
| + | |
| + | The `--inetd` option seemed very promising, but the man-page explicitly states that this option cannot be used for multiple connections, although there seemed to be no reason. (The only reason I found mentioned was that there was no config file templating mechanism, which obviously isn't really a problem). |
| + | |
| + | A test later I found, that the code was written for inetd with "wait=yes" in mind, but that was quickly changed (see attached patch). |
| + | |
| + | The attached patch (merged with OpenVPN as of 1.6-beta5) adds a new option `--inetd nowait` which makes OpenVPN work with a connected socket on stdin, like (x)inetd does with wait=no, or even netcat with the -e option. |
| + | |
| + | Of course, this still runs one OpenVPN process per client. You still need one tap device per client, and configure bridging between them. |
| + | |
| + | This also only works with SSL/TLS and tap devices, because of the single config file shared between all server processes. |
| + | |
| + | The server config file in our case is easy: |
| + | ``` |
| + | # OpenVPN multiple-client-server |
| + | inetd nowait |
| + | proto tcp-server |
| + | |
| + | # 10.254.0.1 is our local VPN endpoint (office). |
| + | dev tap |
| + | ifconfig 10.254.0.1 255.255.255.0 |
| + | |
| + | # Our up script will establish routes once the VPN is alive. |
| + | ifconfig-noexec |
| + | up /etc/openvpn/vpn-server.up |
| + | |
| + | # We are SSL/TLS Server |
| + | tls-server |
| + | dh /etc/openvpn/dh2048.pem |
| + | ca /etc/openvpn/my-ca.crt |
| + | crl-verify /etc/openvpn/my-ca.crl |
| + | cert /etc/openvpn/server.crt |
| + | key /etc/openvpn/server.key |
| + | ``` |
| + | |
| + | The only magic thing is the `ifconfig-noexec`. Of course, we can't `ifconfig` each of the tap interfaces with the same IP address. But we don't need to, as we are using bridging. |
| + | |
| + | My Bridging setup script (run once at bootup): |
| + | ``` |
| + | # load Bridging-Module |
| + | modprobe bridge |
| + | |
| + | # configure bridge |
| + | brctl addbr br0 |
| + | brctl stp br0 off |
| + | brctl setfd br0 0 |
| + | |
| + | # our private vpn network |
| + | ifconfig br0 10.254.0.1 netmask 0xffffff00 broadcast 10.254.0.255 |
| + | ``` |
| + | |
| + | The per-client setup script (vpn-server.up): |
| + | ``` |
| + | # add interface to bridge and activate |
| + | brctl addif br0 $1 |
| + | ifconfig $1 up |
| + | ``` |
| + | |
| + | And for completeness sake, here is the xinetd config file for the OpenVPN server: |
| + | ``` |
| + | service openvpn_1 |
| + | { |
| + | type = UNLISTED |
| + | port = 443 |
| + | socket_type = stream |
| + | protocol = tcp |
| + | wait = no |
| + | user = root |
| + | server = /usr/sbin/openvpn |
| + | server_args = --config /etc/openvpn/vpn-server.conf |
| + | disable = no |
| + | } |
| + | ``` |
| + | |
| + | And that's it. It works for me. If you have any questions or comments, contact me, I'd be happy to hear from you. |
| + | |
| + | CU, |
| + | Stefan `Sec` Zehl |
| + | |
| + | The necessary code changes are very small. Only `socket_listen_accept` needs to be changed. The `accept()` and `openvpn_close_socket()` calls need to be removed, because the connection on stdin is already the connection we want. The second thing is, we have to use `getpeername` to find the IP and Port of our remote peer. |
| + | |
| + | All the other changes in the attached patch deal with adding a new command-line option, and propagating that new option down to the correct function. |