The other ideal solution (IMHO), would be to have openvpn support an
internal routing protocol like ospf. That way you could have tons of
daemon processes (which would also effectively give you multi-processor
support, sort of), and a routing daemon on the host box aggregating all of
those routes together so the OS knows where to send packets. (as a bonus,
those routes could also propagate to other parts of your network)
I'm currently doing this in a hackish sort of way byt having a
client-connect script that includes vtysh commands to inject routes into a
quagga ospf process.
Not that this'd be any easier to implement than listening on multiple
ports, but it'd be pretty cool.
-Joe
On Wed, Mar 30, 2016 at 4:01 PM Gert Doering <g...@greenie.muc.de> wrote:
> Hi,
>
> On Tue, Mar 29, 2016 at 09:20:06AM +0200, Marc Haber wrote:
> > However, the OpenVPN server does not seem to be able to listen on both
> > UDP and TCP, and I need to run a second OpenVPN server to listen on
> > TCP. This makes it impossible to assign the client that is now
> > connected to the fallback TCP server instead of the default UDP server
> > its normal IP addresses, which of course causes a truckload of issues
> > with access lists and DNS.
> >
> > Is there a known and accepted workaround that will allow a client to
> > connect via UDP today and TCP tomorrow while having its normal IP
> > addresses assigned short of running a dedicated OpenVPN server for
> > each such client and restarting it with the port changed if there is
> > the need to do that?
>
> The "canonical" solution as of today is to use a --learn-address script
> (which gets called by the openvpn process as soon as ifconfig-pool and
> iroute processing is done) and set up routing on the linux side towards
> the corresponding tun device for the "UDP server" or the "TCP server".
>
> Yes, this sucks, but it works...
>
>
> The "totally crazy cool" solution will be, of course, to have the server
> listen on multiple ports. It is not easily implemented, though - so far,
> Arne and Heiko have tried to tackle this, and the existing code stubbornly
> refuses cooperation... (historical code evolution from "single peer to
> peer UDP only VPN" to "we can do everything! on all platforms!"...)
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
> //
> www.muc.de/~gert/
> Gert Doering - Munich, Germany
> g...@greenie.muc.de
> fax: +49-89-35655025
> g...@net.informatik.tu-muenchen.de
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
