Re: [Openvpn-users] IPv6 client-to-client communication
Hi, On Thu, Nov 21, 2013 at 06:28:02PM -0500, Ryan Whelan wrote: Does the IPv6 implementation in OpenVPN track multicast memberships? Since I'm using all IPv6, any IGMP snooping implementation wouldn't be of much use. Does OpenVPN just broadcast all the ICMP multicast messages? No, as Andy said, multicast is treated as broadcast. Distribute to all clients. (We differ in that I think multicast/broadcast is *not* forwarded unless client-to-client is enabled, but that needs more testing, obviously) 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-35655025g...@net.informatik.tu-muenchen.de pgpBoMECdqt43.pgp Description: PGP signature -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] IPv6 client-to-client communication
From: Ryan Whelan [mailto:rcwhe...@gmail.com] Sent: November-17-13 2:32 AM To: Gert Doering Cc: openvpn-users@lists.sourceforge.net Subject: Re: [Openvpn-users] IPv6 client-to-client communication The reason I'd been using tap was because the multicast router (mrd6) didn't seem to be working with tun. (the clients will be sending multicast traffic) I'm only slightly familiar with multicast and barely anymore familiar with IPv6; is there a better method to handle multicast traffic from the clients? I will be using multiple servers and OSPF for routing. ==Reply http://community.openvpn.net/openvpn/ticket/79 I think that multicast traffic by default is sending out as broadcast. There is an old patch for that and it might work (see link above) but it is not officially supported. Andy -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] IPv6 client-to-client communication
Hi, On Mon, Nov 18, 2013 at 11:44:36AM +0100, David Sommerseth wrote: On Sun, Nov 17, 2013 at 03:17:05PM -0500, Ryan Whelan wrote: Would it be difficult to modify OpenVPN so it allocated a TAP/TUN per client on connection, so each virtual interface was connected to a single client? (removing it on client disconnect/drop) Significantly so. The code assumes one process, one tun/tap, and many clients comes much later in the flow. And I would be quite concerned about scaling issues in such a model. What happens if someone figures out this is a cool feature for his 500 OpenVPN users? It might expose some scaling issues in Linux, which usually then get fixed :-) - if you can run 500 pptp sessions (each having their own pppX interface), why shouldn't you be able to run 500 tap interfaces...? Whether or not that is a good idea, I can't say - but it certainly would make better usage of all CPUs in a multi-core system than just a single OpenVPN process :-) 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-35655025g...@net.informatik.tu-muenchen.de pgpb_dGMRed4q.pgp Description: PGP signature -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] IPv6 client-to-client communication
Hi, On Mon, Nov 18, 2013 at 09:30:51AM -0500, Ryan Whelan wrote: Would it be possible to spawn multiple processes, one for each client/tun/tap (with some configurable limit possibly)? It would also help with multiprocessing! I have some machines with multiple processors which are mostly a waste it seems. All is possible, if someone adds the code to do it... If you run openvpn over TCP, you can do --inetd and run it from (x)inetd, but that won't work for UDP. For UDP you really need a different port number per process, so auto-forking would ether need bound sockets, or some sort of dispatcher process... all quite non-trivial. 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-35655025g...@net.informatik.tu-muenchen.de pgp5gzn4g4FcJ.pgp Description: PGP signature -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] IPv6 client-to-client communication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18. nov. 2013 15:30, Ryan Whelan wrote: Would it be possible to spawn multiple processes, one for each client/tun/tap (with some configurable limit possibly)? It would also help with multiprocessing! I have some machines with multiple processors which are mostly a waste it seems. Yeah, threading would help to some degree. I'm not a threading expert, but have written a few multi-threaded programs. For those programs which required the CPU to work a lot, it was never a good idea to have more threads than CPU cores - that actually had the opposite effect. If you have more CPU intensive threads than CPU cores, those intensive threads needs to share a limited mount of CPU resources, this reducing the overall performance noticeably. If the workload is _not_ CPU intensive, then you can have somewhat better response when one of the threads suddenly wake up and you have idle CPU cores. But in the moment more threads than CPU cores require attention, then this strategy is clearly wrong. OpenVPN is now somewhat timer/event based in a single thread. So to make OpenVPN really efficient on multiple cores, I believe having a thread for processing of the TCP/UDP socket, another thread tackling the TUN/TAP adapter and maybe separate threads for encryption/decryption and key re-negotiating will have a bigger performance impact than a single thread per connection. This way tunnel data can pass through the TCP/UDP sockets or to/from the tun/tap device independently, and esp. key re-negotiation which is CPU intensive will not block the transport threads before the new keying material is ready. Having this said: I used to be a firm believer earlier on that separate threads per clients was the way to go. But I've experience it differently in some other projects. - -- kind regards, David Sommerseth On Sun, Nov 17, 2013 at 4:44 PM, Gert Doering g...@greenie.muc.de mailto:g...@greenie.muc.de wrote: Hi, On Sun, Nov 17, 2013 at 03:17:05PM -0500, Ryan Whelan wrote: Would it be difficult to modify OpenVPN so it allocated a TAP/TUN per client on connection, so each virtual interface was connected to a single client? (removing it on client disconnect/drop) Significantly so. The code assumes one process, one tun/tap, and many clients comes much later in the flow. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ http://www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de mailto:g...@greenie.muc.de fax: +49-89-35655025 tel:%2B49-89-35655025 g...@net.informatik.tu-muenchen.de mailto:g...@net.informatik.tu-muenchen.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKKLMYACgkQDC186MBRfrpSvwCfbzN0+e4qE5nIu6aoHP6IfFRV X2MAoISuljg7IEyxLT0l/xOwFSq4pviB =J6vE -END PGP SIGNATURE- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] IPv6 client-to-client communication
Hi, On Sun, Nov 17, 2013 at 02:31:33AM -0500, Ryan Whelan wrote: The reason I'd been using tap was because the multicast router (mrd6) didn't seem to be working with tun. (the clients will be sending multicast traffic) I'm only slightly familiar with multicast and barely anymore familiar with IPv6; is there a better method to handle multicast traffic from the clients? I will be using multiple servers and OSPF for routing. If you want to do multicast routing, you need tap indeed (or, to be specific, anything that is more complex routing-wise than openvpn can do - which is static unicast routing and link-local multicast). In that case, you'll have to use client-to-client, as regular multicast forwarding will have the same problem as ND - what comes in via tap0 will never go out via tap0 again, as the kernel assumes that everyone else on tap0 has already seen the packet (one of the fundamentals of multicast routing). If you can't use client-to-client, you'll have to modify the multicast forwarding logic inside the openvpn server code to work independent of whether client-to-client is active - but then you can't filter multicast traffic either. (If you only have a handful of clients, you might also run one server instance per client, and bridge all the tapX interface together via brctl... or have independent subnets and do full multicast routing) 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-35655025g...@net.informatik.tu-muenchen.de pgpQqGOk0U2X1.pgp Description: PGP signature -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] IPv6 client-to-client communication
Would it be difficult to modify OpenVPN so it allocated a TAP/TUN per client on connection, so each virtual interface was connected to a single client? (removing it on client disconnect/drop) This is going to be a shared environment and the ability to apply security to individual interfaces via a script run on the server at connection time would be huge. Thanks for all your help! You've been very helpful! ryan On Sun, Nov 17, 2013 at 3:18 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Sun, Nov 17, 2013 at 02:31:33AM -0500, Ryan Whelan wrote: The reason I'd been using tap was because the multicast router (mrd6) didn't seem to be working with tun. (the clients will be sending multicast traffic) I'm only slightly familiar with multicast and barely anymore familiar with IPv6; is there a better method to handle multicast traffic from the clients? I will be using multiple servers and OSPF for routing. If you want to do multicast routing, you need tap indeed (or, to be specific, anything that is more complex routing-wise than openvpn can do - which is static unicast routing and link-local multicast). In that case, you'll have to use client-to-client, as regular multicast forwarding will have the same problem as ND - what comes in via tap0 will never go out via tap0 again, as the kernel assumes that everyone else on tap0 has already seen the packet (one of the fundamentals of multicast routing). If you can't use client-to-client, you'll have to modify the multicast forwarding logic inside the openvpn server code to work independent of whether client-to-client is active - but then you can't filter multicast traffic either. (If you only have a handful of clients, you might also run one server instance per client, and bridge all the tapX interface together via brctl... or have independent subnets and do full multicast routing) 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 -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] IPv6 client-to-client communication
Hi, On Sun, Nov 17, 2013 at 03:17:05PM -0500, Ryan Whelan wrote: Would it be difficult to modify OpenVPN so it allocated a TAP/TUN per client on connection, so each virtual interface was connected to a single client? (removing it on client disconnect/drop) Significantly so. The code assumes one process, one tun/tap, and many clients comes much later in the flow. 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-35655025g...@net.informatik.tu-muenchen.de pgpzcNhmxRhJL.pgp Description: PGP signature -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] IPv6 client-to-client communication
I have a (tap) server setup with `topology subnet` and an IPv6 pool configured `server-ipv6 fdda:ba64:dcdc:1::1/64' Clients can connect, get IPv6 addresses and ping the server on the address it assigns its tap interface (fdda:ba64:dcdc:1::2). The clients can not communicate with one another- functionality that is required for my application. Running two instances of openvpn on the server DOES allow the clients to communicate (with a single client connected to each instance) so I know the server is configured to route IPv6 traffic correctly. I can't use the client-to-client functionality in openvpn because I will need to do traffic filtering in the server. With 2 clients connected with the addresses fdda:ba64:dcdc:1::1002 and fdda:ba64:dcdc:1::1001, when trying to ping from one to the other, I can see the NDP traffic on the server's tap interface- 03:55:01.978033 IP6 fdda:ba64:dcdc:1::1002 ff02::1:ff00:1001: ICMP6, neighbor solicitation, who has fdda:ba64:dcdc:1::1001, length 32 03:55:02.977670 IP6 fdda:ba64:dcdc:1::1002 ff02::1:ff00:1001: ICMP6, neighbor solicitation, who has fdda:ba64:dcdc:1::1001, length 32 03:55:03.977732 IP6 fdda:ba64:dcdc:1::1002 ff02::1:ff00:1001: ICMP6, neighbor solicitation, who has fdda:ba64:dcdc:1::1001, length 32 03:55:04.978194 IP6 fdda:ba64:dcdc:1::1002 ff02::1:ff00:1001: ICMP6, neighbor solicitation, who has fdda:ba64:dcdc:1::1001, length 32 03:55:05.977656 IP6 fdda:ba64:dcdc:1::1002 ff02::1:ff00:1001: ICMP6, neighbor solicitation, who has fdda:ba64:dcdc:1::1001, length 32 Is this an issue with the IPv6 multicast implementation in openvpn? Is there some extra server configuration necessary for Linux to route IPv6 multicast traffic in-and-out the same interface? I'm not quite sure where to look from here- thanks for any pointers! ryan -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] IPv6 client-to-client communication
Hi, On Sat, Nov 16, 2013 at 11:45:37PM -0500, Ryan Whelan wrote: With 2 clients connected with the addresses fdda:ba64:dcdc:1::1002 and fdda:ba64:dcdc:1::1001, when trying to ping from one to the other, I can see the NDP traffic on the server's tap interface- 03:55:01.978033 IP6 fdda:ba64:dcdc:1::1002 ff02::1:ff00:1001: ICMP6, neighbor solicitation, who has fdda:ba64:dcdc:1::1001, length 32 That is actually a fairly interesting problem. The Linux side will not send out the multicast *back* onto the TAP interface where it came from, because that is a good way to cause packet loops, so you just don't do that. OpenVPN won't forward the multicasts to the other client as well, because you told it not to do so (it will, if client-to-client is used). It could be hacked into OpenVPN (permit neighbour discovery IPv6 mcast, even if client-to-client is off), but that's not exactly trivial. You could use *tun* instead of tap, which does not have ND, so doesn't suffer from multicast forwarding issues. This is what I would do. Or you could add static nd entries (ip neigh add on Linux) on the clients... this might need some more trickery in the --up script to ensure a constant MAC address on the tap interface, otherwise static ND on the other clients will not work right. 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-35655025g...@net.informatik.tu-muenchen.de pgpQIkxSHJeLE.pgp Description: PGP signature -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] IPv6 client-to-client communication
The reason I'd been using tap was because the multicast router (mrd6) didn't seem to be working with tun. (the clients will be sending multicast traffic) I'm only slightly familiar with multicast and barely anymore familiar with IPv6; is there a better method to handle multicast traffic from the clients? I will be using multiple servers and OSPF for routing. On Sun, Nov 17, 2013 at 2:03 AM, Gert Doering g...@greenie.muc.de wrote: Hi, On Sat, Nov 16, 2013 at 11:45:37PM -0500, Ryan Whelan wrote: With 2 clients connected with the addresses fdda:ba64:dcdc:1::1002 and fdda:ba64:dcdc:1::1001, when trying to ping from one to the other, I can see the NDP traffic on the server's tap interface- 03:55:01.978033 IP6 fdda:ba64:dcdc:1::1002 ff02::1:ff00:1001: ICMP6, neighbor solicitation, who has fdda:ba64:dcdc:1::1001, length 32 That is actually a fairly interesting problem. The Linux side will not send out the multicast *back* onto the TAP interface where it came from, because that is a good way to cause packet loops, so you just don't do that. OpenVPN won't forward the multicasts to the other client as well, because you told it not to do so (it will, if client-to-client is used). It could be hacked into OpenVPN (permit neighbour discovery IPv6 mcast, even if client-to-client is off), but that's not exactly trivial. You could use *tun* instead of tap, which does not have ND, so doesn't suffer from multicast forwarding issues. This is what I would do. Or you could add static nd entries (ip neigh add on Linux) on the clients... this might need some more trickery in the --up script to ensure a constant MAC address on the tap interface, otherwise static ND on the other clients will not work right. 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 -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
