[eduVPN-deploy] Question re connections per process

Louis Twomey louis.twomey at heanet.ie
Tue Apr 28 19:42:30 CEST 2020


Hi Tangui,
So far we have implemented eduVPN just for our own staff, and for the staff of a subsidiary company. Both are small-scale services, there are fewer than 70 staff in each company. The services have been working very well.

We are in conversation with our clients about implementing a service for their staff, and perhaps their students. At this point we are just trying to determine whether clients are interested, so implementation is weeks/months away if it happens at all. Many of our clients are very small, but some of the bigger colleges and universities would need to cater for thousands of staff (and obviously a lot more if including students), and that's where we would face a challenge.

So far none of our clients have said they need a VPN service from us, but we are continuing to discuss it with them.

Thanks too for your offer of help.

Regards,
Louis
-------
Louis Twomey
Senior Network Engineer
PGP key: C77D9256
HEAnet CLG, Ireland’s National Education and Research Network
1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland
+353 (0)1 6609040   louis.twomey at heanet.ie  www.heanet.ie
Registered in Ireland, No. 275301.  CRA No. 20036270

________________________________________
From: Tangui Coulouarn <tangui.coulouarn at deic.dk>
Sent: Tuesday 28 April 2020 08:50
To: Louis Twomey
Cc: François Kooman; eduvpn-deploy at list.surfnet.nl
Subject: Re: [eduVPN-deploy] Question re connections per process

CAUTION[External]: This email originated from outside of the organisation. Do not click on links or open the attachments unless you recognise the sender and know the content is safe.


Hi Louis,

How did it go with your eduVPN installation? Can we help in any way?

Best regards,

Tangui

> On 7 Apr 2020, at 18.40, Louis Twomey <louis.twomey at heanet.ie> wrote:
>
> Thank you very much François, and Rogier, that is extremely helpful!
>
> I had read most of the documents you both linked to, but somehow I had missed SCALING.md - reading that now has provided further useful information.
>
> Thanks, and regards,
> Louis.
>
> -------
> Louis Twomey
> Technical Architect
> PGP key: C77D9256
> HEAnet CLG, Ireland’s National Education and Research Network
> 1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland
> +353 (0)1 6609040   louis.twomey at heanet.ie  www.heanet.ie
> Registered in Ireland, No. 275301.  CRA No. 20036270
>
>
>
>> On 7 Apr 2020, at 10:45, François Kooman <fkooman at tuxed.net> wrote:
>>
>> CAUTION[External]: This email originated from outside of the organisation. Do not click on links or open the attachments unless you recognise the sender and know the content is safe.
>>
>>
>> On 4/7/20 11:09 AM, Louis Twomey wrote:
>>> Thanks François.
>>
>> Hi Louis,
>>
>>> A scenario that we might face is a client with 1,000 users, and a
>>> single eduVPN server listening on two ports (1194/udp and 443/tcp)
>>> and allocated a single /22 IP range.
>>
>> That is not ideal as OpenVPN is not multi-threaded. So in this setup
>> you'd be able to use a maximum of 2 cores only.
>>
>>> With a suitable server (16 x CPU cores, 6GB RAM), theoretically we
>>> could run just two OpenVPN processes. But, in terms of performance,
>>> would this be a good idea i.e. would each OpenVPN process really be
>>> capable of handling a load of up to 500 simultaneous connections?
>>
>> RAM is not a bottleneck as far as I can tell! So doesn't have to be
>> excessive :)
>>
>> With 16 cores you want >= 16 OpenVPN processes...
>>
>>> Or would the server perform better if we configured its network
>>> interface with 16 public IP addresses, and listened on 2 ports per IP
>>> address (allocating a /26 IP range per port), so that each OpenVPN
>>> process would have to handle a max of 64 simultaneous connections?
>>
>> Either that, or better listen on different ports starting at 1194, 1195,
>> 1196, ... and have udp/443 and tcp/443 as "fallback" ports there as
>> well. That's how we do it to avoid needing multiple public IP addresses
>> for the server(s) and keep IPv6 support for clients with native IPv6
>> network.
>>
>>> * If the server has reached the max number of simultaneous
>>> connections on a port, when the next eduVPN client tries to connect,
>>> will it automatically failover to the next port defined in the
>>> profile? I know the failover happens successfully when a port is
>>> unreachable, but I haven’t tested what happens when a port is
>>> reachable but “full”
>>
>> This requires more extensive testing on especially iOS and macOS as they
>> use a different OpenVPN client (Tunnelkit).
>>
>> Due to the "load balancing" as implemented in eduVPN the clients will
>> automatically be distributed over the OpenVPN processes... so the
>> OpenVPN processes will be full more or less at the same time...
>>
>>> * If I build a server with 16 interface IP addresses, listening on 2
>>> ports per IP, is it possible to have eduVPN clients failover across
>>> the 16 IP addresses i.e. is it possible to create a single/common
>>> profile for all end-users with this architecture?
>>
>> The problem with this approach is that it indeed would require a profile
>> for every public IP address, which is sub-optimal. It *can* work though
>> with round robin DNS, but I would definitely not recommend this. You'll
>> also lose listening on IPv6 (or IPv4). Unfortunately this is due to the
>> way OpenVPN works, not much we can do about it at this time. Maybe in
>> future versions of OpenVPN. Your proposed solution would be appropriate
>> if you have multiple VMs/physical servers to distribute the load.
>>
>> For more info see
>> https://github.com/eduvpn/documentation/blob/v2/SCALING.md and
>> https://github.com/eduvpn/documentation/blob/v2/PORT_SHARING.md.
>>
>> Let me know if you have any more questions!
>>
>> Regards,
>> François
>
> _______________________________________________
> eduVPN-deploy mailing list
> eduVPN-deploy at list.surfnet.nl
> https://list.surfnet.nl/mailman/listinfo/eduvpn-deploy




More information about the eduVPN-deploy mailing list