openvpn-devel Mailing List for OpenVPN

Ok now I understand what is happening, thanks for your answers guys.   ________________________________ From: Gert Doering <ge...@gr...> To: ehsan enayati <ehs...@ya...> Cc: Gert Doering <ge...@gr...>; "ope...@li..." <ope...@li...> Sent: Tuesday, September 25, 2012 11:27 AM Subject: Re: [Openvpn-devel] multi threading support Hi, On Tue, Sep 25, 2012 at 12:22:40AM -0700, ehsan enayati wrote: > I saw in the linux source code that it uses fork and pthread, i think that's the way it handles multiple requests Neither. Fork() is used to, uh, fork other processes (for example to start scripts). pthread is not used at all - there was some experimental code that used multithreading to get crypto into its own thread, but that has been removed for 2.3 because it wasn't complete and didn't work. Multiple requests are just queued in a, uh, "work queue" - which is basically a glorified array of things-to-do - and then processed one after another. gert -- USENET is *not* the non-clickable part of WWW!                                                           //www.muc.de/~gert/ Gert Doering - Munich, Germany                            ge...@gr... fax: +49-89-35655025                        ge...@ne...

Hi, On Tue, Sep 25, 2012 at 12:22:40AM -0700, ehsan enayati wrote: > I saw in the linux source code that it uses fork and pthread, i think that's the way it handles multiple requests Neither. Fork() is used to, uh, fork other processes (for example to start scripts). pthread is not used at all - there was some experimental code that used multithreading to get crypto into its own thread, but that has been removed for 2.3 because it wasn't complete and didn't work. Multiple requests are just queued in a, uh, "work queue" - which is basically a glorified array of things-to-do - and then processed one after another. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

I saw in the linux source code that it uses fork and pthread, i think that's the way it handles multiple requests ________________________________ From: Gert Doering <ge...@gr...> To: ehsan enayati <ehs...@ya...> Cc: "ope...@li..." <ope...@li...> Sent: Monday, September 24, 2012 12:48 PM Subject: Re: [Openvpn-devel] multi threading support Hi, On Mon, Sep 24, 2012 at 02:00:46AM -0700, ehsan enayati wrote: > Hi, i wanna know how does openvpn server handles multiple requests? > for example if there is an active connection with a client on 1194 > port and another requests from some other client comes in what will > happen? Is this task managed in operating system or by openvpn > itself? OpenVPN itself (single-threaded with smart work queues). Multi-Threading might happen in OpenVPN 3.0. gert -- USENET is *not* the non-clickable part of WWW!                                                           //www.muc.de/~gert/ Gert Doering - Munich, Germany                            ge...@gr... fax: +49-89-35655025                        ge...@ne...

24.09.2012 19:20, Gert Doering wrote: > Hi, > > On Mon, Sep 24, 2012 at 02:56:50AM -0700, ehsan enayati wrote: >> thanks for your quick reply, I know that openvpn is single threaded but it supports multiple user connection simultaneously, I wanted to know how this is done although it just have one thread. > > "by sufficiently advanced magic" > The magic is called "multiplexing connections" :) 

On 09/24/2012 07:30 PM, Krzysztof Witek wrote: > On 09/24/2012 07:28 PM, Davide Brini wrote: >> On Mon, 24 Sep 2012 19:20:18 +0200, Krzysztof Witek <ne...@wi...> wrote: >> >>> From: Krzysztof Witek <krz...@wi...> >>> >>> If multiple ip addresses of the same subnet are configured on an >>> interface, openvpn may not send udp datagrams to the peer >>> using the correct source ip address. >>> >>> If a host sends the udp datagrams to the ip address A, then it >>> should receive the answer from A even if the its peer has multiple >>> ip addresses and the default routing selects a different one. >>> >>> The issue can be reproduced with the following scenario: >>> >>> Host A is connected to two gateways each on the same subnet: >>> gw1 with ip address 10.0.0.254 >>> gw2 with ip address 10.0.0.253 >>> >>> Host A has two ip addresses: 10.0.0.1 and 10.0.0.2. >>> It receives DNAT-ed traffic from gw1 via 10.0.0.1 >>> and DNAT-ed traffic from gw2 via 10.0.0.2. >>> >>> Two ip rules are set up on the host A: >>> ip rule add from 10.0.0.1 table 1 >>> ip rule add from 10.0.0.2 table 2 >>> >>> and three default routes: >>> ip route add default via 10.0.0.254 table 1 >>> ip route add default via 10.0.0.253 table 2 >>> ip route add default via 10.0.0.254 >>> >>> This way all traffic from 10.0.0.1 will go via 10.0.0.254 >>> and all traffic from 10.0.0.2 will go via 10.0.0.253. >>> >>> The current openvpn server doesn't work if it receives a connection >>> from the router gw2 because it will send its udp datagrams via gw1. >>> >>> Saving the destination ip address on which the udp datagram arrived and >>> then using it as the source ip address solves this issue. >> I haven't checked, but doesn't --multihome work in this case? >> > no, it doesn't seem to work > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel sorry, checked with a wrong version, it does work with --multihome the patch can be dropped thanks 

On 09/24/2012 07:28 PM, Davide Brini wrote: > On Mon, 24 Sep 2012 19:20:18 +0200, Krzysztof Witek <ne...@wi...> wrote: > >> From: Krzysztof Witek <krz...@wi...> >> >> If multiple ip addresses of the same subnet are configured on an >> interface, openvpn may not send udp datagrams to the peer >> using the correct source ip address. >> >> If a host sends the udp datagrams to the ip address A, then it >> should receive the answer from A even if the its peer has multiple >> ip addresses and the default routing selects a different one. >> >> The issue can be reproduced with the following scenario: >> >> Host A is connected to two gateways each on the same subnet: >> gw1 with ip address 10.0.0.254 >> gw2 with ip address 10.0.0.253 >> >> Host A has two ip addresses: 10.0.0.1 and 10.0.0.2. >> It receives DNAT-ed traffic from gw1 via 10.0.0.1 >> and DNAT-ed traffic from gw2 via 10.0.0.2. >> >> Two ip rules are set up on the host A: >> ip rule add from 10.0.0.1 table 1 >> ip rule add from 10.0.0.2 table 2 >> >> and three default routes: >> ip route add default via 10.0.0.254 table 1 >> ip route add default via 10.0.0.253 table 2 >> ip route add default via 10.0.0.254 >> >> This way all traffic from 10.0.0.1 will go via 10.0.0.254 >> and all traffic from 10.0.0.2 will go via 10.0.0.253. >> >> The current openvpn server doesn't work if it receives a connection >> from the router gw2 because it will send its udp datagrams via gw1. >> >> Saving the destination ip address on which the udp datagram arrived and >> then using it as the source ip address solves this issue. > I haven't checked, but doesn't --multihome work in this case? > no, it doesn't seem to work 

On Mon, 24 Sep 2012 19:20:18 +0200, Krzysztof Witek <ne...@wi...> wrote: > From: Krzysztof Witek <krz...@wi...> > > If multiple ip addresses of the same subnet are configured on an > interface, openvpn may not send udp datagrams to the peer > using the correct source ip address. > > If a host sends the udp datagrams to the ip address A, then it > should receive the answer from A even if the its peer has multiple > ip addresses and the default routing selects a different one. > > The issue can be reproduced with the following scenario: > > Host A is connected to two gateways each on the same subnet: > gw1 with ip address 10.0.0.254 > gw2 with ip address 10.0.0.253 > > Host A has two ip addresses: 10.0.0.1 and 10.0.0.2. > It receives DNAT-ed traffic from gw1 via 10.0.0.1 > and DNAT-ed traffic from gw2 via 10.0.0.2. > > Two ip rules are set up on the host A: > ip rule add from 10.0.0.1 table 1 > ip rule add from 10.0.0.2 table 2 > > and three default routes: > ip route add default via 10.0.0.254 table 1 > ip route add default via 10.0.0.253 table 2 > ip route add default via 10.0.0.254 > > This way all traffic from 10.0.0.1 will go via 10.0.0.254 > and all traffic from 10.0.0.2 will go via 10.0.0.253. > > The current openvpn server doesn't work if it receives a connection > from the router gw2 because it will send its udp datagrams via gw1. > > Saving the destination ip address on which the udp datagram arrived and > then using it as the source ip address solves this issue. I haven't checked, but doesn't --multihome work in this case? -- D. 

From: Krzysztof Witek <krz...@wi...> If multiple ip addresses of the same subnet are configured on an interface, openvpn may not send udp datagrams to the peer using the correct source ip address. If a host sends the udp datagrams to the ip address A, then it should receive the answer from A even if the its peer has multiple ip addresses and the default routing selects a different one. The issue can be reproduced with the following scenario: Host A is connected to two gateways each on the same subnet: gw1 with ip address 10.0.0.254 gw2 with ip address 10.0.0.253 Host A has two ip addresses: 10.0.0.1 and 10.0.0.2. It receives DNAT-ed traffic from gw1 via 10.0.0.1 and DNAT-ed traffic from gw2 via 10.0.0.2. Two ip rules are set up on the host A: ip rule add from 10.0.0.1 table 1 ip rule add from 10.0.0.2 table 2 and three default routes: ip route add default via 10.0.0.254 table 1 ip route add default via 10.0.0.253 table 2 ip route add default via 10.0.0.254 This way all traffic from 10.0.0.1 will go via 10.0.0.254 and all traffic from 10.0.0.2 will go via 10.0.0.253. The current openvpn server doesn't work if it receives a connection from the router gw2 because it will send its udp datagrams via gw1. Saving the destination ip address on which the udp datagram arrived and then using it as the source ip address solves this issue. Signed-off-by: Krzysztof Witek <krz...@wi...> --- src/openvpn/forward.c | 6 ++++-- src/openvpn/openvpn.h | 1 + src/openvpn/socket.c | 19 +++++++++++-------- src/openvpn/socket.h | 28 ++++++++++++++++++---------- 4 files changed, 34 insertions(+), 20 deletions(-) diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c index 57c7846..6e629c2 100644 --- a/src/openvpn/forward.c +++ b/src/openvpn/forward.c @@ -674,7 +674,8 @@ read_incoming_link (struct context *c) status = link_socket_read (c->c2.link_socket, &c->c2.buf, MAX_RW_SIZE_LINK (&c->c2.frame), - &c->c2.from); + &c->c2.from, + &c->c2.to); if (socket_connection_reset (c->c2.link_socket, status)) { @@ -1135,7 +1136,8 @@ process_outgoing_link (struct context *c) /* Send packet */ size = link_socket_write (c->c2.link_socket, &c->c2.to_link, - to_addr); + to_addr, + &c->c2.to); #ifdef ENABLE_SOCKS /* Undo effect of prepend */ diff --git a/src/openvpn/openvpn.h b/src/openvpn/openvpn.h index 7abfb08..53a3c00 100644 --- a/src/openvpn/openvpn.h +++ b/src/openvpn/openvpn.h @@ -258,6 +258,7 @@ struct context_2 struct link_socket_actual *to_link_addr; /* IP address of remote */ struct link_socket_actual from; /* address of incoming datagram */ + struct link_socket_actual to; /* address of local datagram */ /* MTU frame parameters */ struct frame frame; diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c index 505cf3b..0f57973 100644 --- a/src/openvpn/socket.c +++ b/src/openvpn/socket.c @@ -653,7 +653,7 @@ create_socket_udp (const unsigned int flags) { int pad = 1; #ifdef IP_PKTINFO - if (setsockopt (sd, SOL_IP, IP_PKTINFO, + if (setsockopt (sd, IPPROTO_IP, IP_PKTINFO, (void*)&pad, sizeof(pad)) < 0) msg(M_ERR, "UDP: failed setsockopt for IP_PKTINFO"); #elif defined(IP_RECVDSTADDR) @@ -2657,7 +2657,8 @@ static socklen_t link_socket_read_udp_posix_recvmsg (struct link_socket *sock, struct buffer *buf, int maxsize, - struct link_socket_actual *from) + struct link_socket_actual *from, + struct link_socket_actual *to) { struct iovec iov; union openvpn_pktinfo opi; @@ -2680,11 +2681,10 @@ link_socket_read_udp_posix_recvmsg (struct link_socket *sock, cmsg = CMSG_FIRSTHDR (&mesg); if (cmsg != NULL && CMSG_NXTHDR (&mesg, cmsg) == NULL + && cmsg->cmsg_level == IPPROTO_IP #ifdef IP_PKTINFO - && cmsg->cmsg_level == SOL_IP && cmsg->cmsg_type == IP_PKTINFO #elif defined(IP_RECVDSTADDR) - && cmsg->cmsg_level == IPPROTO_IP && cmsg->cmsg_type == IP_RECVDSTADDR #else #error ENABLE_IP_PKTINFO is set without IP_PKTINFO xor IP_RECVDSTADDR (fix syshead.h) @@ -2695,6 +2695,7 @@ link_socket_read_udp_posix_recvmsg (struct link_socket *sock, struct in_pktinfo *pkti = (struct in_pktinfo *) CMSG_DATA (cmsg); from->pi.in4.ipi_ifindex = pkti->ipi_ifindex; from->pi.in4.ipi_spec_dst = pkti->ipi_spec_dst; + to->pi.in4.ipi_addr = pkti->ipi_addr; #elif defined(IP_RECVDSTADDR) from->pi.in4 = *(struct in_addr*) CMSG_DATA (cmsg); #else @@ -2720,7 +2721,8 @@ int link_socket_read_udp_posix (struct link_socket *sock, struct buffer *buf, int maxsize, - struct link_socket_actual *from) + struct link_socket_actual *from, + struct link_socket_actual *to) { socklen_t fromlen = sizeof (from->dest.addr); socklen_t expectedlen = af_addr_size(proto_sa_family(sock->info.proto)); @@ -2729,7 +2731,7 @@ link_socket_read_udp_posix (struct link_socket *sock, #if ENABLE_IP_PKTINFO /* Both PROTO_UDPv4 and PROTO_UDPv6 */ if (proto_is_udp(sock->info.proto) && sock->sockflags & SF_USE_IP_PKTINFO) - fromlen = link_socket_read_udp_posix_recvmsg (sock, buf, maxsize, from); + fromlen = link_socket_read_udp_posix_recvmsg (sock, buf, maxsize, from, to); else #endif buf->len = recvfrom (sock->sd, BPTR (buf), maxsize, 0, @@ -2767,7 +2769,8 @@ link_socket_write_tcp (struct link_socket *sock, int link_socket_write_udp_posix_sendmsg (struct link_socket *sock, struct buffer *buf, - struct link_socket_actual *to) + struct link_socket_actual *to, + struct link_socket_actual *from) { struct iovec iov; struct msghdr mesg; @@ -2797,7 +2800,7 @@ link_socket_write_udp_posix_sendmsg (struct link_socket *sock, pkti = (struct in_pktinfo *) CMSG_DATA (cmsg); pkti->ipi_ifindex = to->pi.in4.ipi_ifindex; pkti->ipi_spec_dst = to->pi.in4.ipi_spec_dst; - pkti->ipi_addr.s_addr = 0; + pkti->ipi_addr = from->pi.in4.ipi_addr; } #elif defined(IP_RECVDSTADDR) cmsg->cmsg_level = IPPROTO_IP; diff --git a/src/openvpn/socket.h b/src/openvpn/socket.h index 44f1098..7aad95f 100644 --- a/src/openvpn/socket.h +++ b/src/openvpn/socket.h @@ -867,7 +867,8 @@ link_socket_read_udp_win32 (struct link_socket *sock, int link_socket_read_udp_posix (struct link_socket *sock, struct buffer *buf, int maxsize, - struct link_socket_actual *from); + struct link_socket_actual *from, + struct link_socket_actual *to); #endif @@ -876,16 +877,18 @@ static inline int link_socket_read (struct link_socket *sock, struct buffer *buf, int maxsize, - struct link_socket_actual *from) + struct link_socket_actual *from, + struct link_socket_actual *to) { if (proto_is_udp(sock->info.proto)) /* unified UDPv4 and UDPv6 */ { int res; #ifdef WIN32 + (void) to; res = link_socket_read_udp_win32 (sock, buf, from); #else - res = link_socket_read_udp_posix (sock, buf, maxsize, from); + res = link_socket_read_udp_posix (sock, buf, maxsize, from, to); #endif return res; } @@ -940,16 +943,18 @@ link_socket_write_win32 (struct link_socket *sock, static inline int link_socket_write_udp_posix (struct link_socket *sock, struct buffer *buf, - struct link_socket_actual *to) + struct link_socket_actual *to, + struct link_socket_actual *from) { #if ENABLE_IP_PKTINFO int link_socket_write_udp_posix_sendmsg (struct link_socket *sock, struct buffer *buf, - struct link_socket_actual *to); + struct link_socket_actual *to, + struct link_socket_actual *from); if (proto_is_udp(sock->info.proto) && (sock->sockflags & SF_USE_IP_PKTINFO) && addr_defined_ipi(to)) - return link_socket_write_udp_posix_sendmsg (sock, buf, to); + return link_socket_write_udp_posix_sendmsg (sock, buf, to, from); else #endif return sendto (sock->sd, BPTR (buf), BLEN (buf), 0, @@ -970,12 +975,14 @@ link_socket_write_tcp_posix (struct link_socket *sock, static inline int link_socket_write_udp (struct link_socket *sock, struct buffer *buf, - struct link_socket_actual *to) + struct link_socket_actual *to, + struct link_socket_actual *from) { #ifdef WIN32 + (void) from; return link_socket_write_win32 (sock, buf, to); #else - return link_socket_write_udp_posix (sock, buf, to); + return link_socket_write_udp_posix (sock, buf, to, from); #endif } @@ -983,11 +990,12 @@ link_socket_write_udp (struct link_socket *sock, static inline int link_socket_write (struct link_socket *sock, struct buffer *buf, - struct link_socket_actual *to) + struct link_socket_actual *to, + struct link_socket_actual *from) { if (proto_is_udp(sock->info.proto)) /* unified UDPv4 and UDPv6 */ { - return link_socket_write_udp (sock, buf, to); + return link_socket_write_udp (sock, buf, to, from); } else if (proto_is_tcp(sock->info.proto)) /* unified TCPv4 and TCPv6 */ { -- 1.7.0.4 

Hi, On Mon, Sep 24, 2012 at 02:56:50AM -0700, ehsan enayati wrote: > thanks for your quick reply, I know that openvpn is single threaded but it supports multiple user connection simultaneously, I wanted to know how this is done although it just have one thread. "by sufficiently advanced magic" gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

thanks for your quick reply, I know that openvpn is single threaded but it supports multiple user connection simultaneously, I wanted to know how this is done although it just have one thread. thanks   - ________________________________ From: Gert Doering <ge...@gr...> To: ehsan enayati <ehs...@ya...> Cc: "ope...@li..." <ope...@li...> Sent: Monday, September 24, 2012 12:48 PM Subject: Re: [Openvpn-devel] multi threading support Hi, On Mon, Sep 24, 2012 at 02:00:46AM -0700, ehsan enayati wrote: > Hi, i wanna know how does openvpn server handles multiple requests? > for example if there is an active connection with a client on 1194 > port and another requests from some other client comes in what will > happen? Is this task managed in operating system or by openvpn > itself? OpenVPN itself (single-threaded with smart work queues). Multi-Threading might happen in OpenVPN 3.0. gert -- USENET is *not* the non-clickable part of WWW!                                                           //www.muc.de/~gert/ Gert Doering - Munich, Germany                            ge...@gr... fax: +49-89-35655025                        ge...@ne...

Hi, On Mon, Sep 24, 2012 at 02:00:46AM -0700, ehsan enayati wrote: > Hi, i wanna know how does openvpn server handles multiple requests? > for example if there is an active connection with a client on 1194 > port and another requests from some other client comes in what will > happen? Is this task managed in operating system or by openvpn > itself? OpenVPN itself (single-threaded with smart work queues). Multi-Threading might happen in OpenVPN 3.0. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

Hi, i wanna know how does openvpn server handles multiple requests? for example if there is an active connection with a client on 1194 port and another requests from some other client comes in what will happen? Is this task managed in operating system or by openvpn itself? Thanks 

Hi, I have installed the TAP-WIN32 Adapter V9 on my windows 7 machine. I want to use TUN to read the IP packets out of the interface. I followed the C# sample from http://www.varsanofiev.com/inside/using_tuntap_under_windows.htm  i modified the code like below IntPtr ptun = Marshal.AllocHGlobal(8);         Marshal.WriteInt32(ptun, 0, 0x0a030001); Marshal.WriteInt32(ptun, 4, unchecked((int)0x00ffffFF)); bool val = DeviceIoControl (ptr, TAP_CONTROL_CODE (5, METHOD_BUFFERED) /*POINT TO POINT */, ptun, 8,ptun, 8, out len, IntPtr.Zero); However i still don't seem to get IP Packets. I ran tcpdump on the other end and it complains "Wrong link layer encapsulation". Is this the correct way of trying to get IP Packets out of TUN interface?. -Vijay 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/09/12 14:42, C.I.G IT SUPPORT wrote: > Hello David, Hi, First of all, support goes in the public. No private posting, otherwise other people can't learn and it looks like nobody gets help on the mailing list. > What does it mean ? It means: read the documentation > Listen dude, I'll explain you more about my Network > infrastructure.. > > Server side: LAN ---> ISA Server----> router----> WAN. LAN: > 192.168.0.x ISA: internal NIC 192.168.0.8, External NIC > 192.168.2.50 Router: 192.168.2.100 > Client Side: LAN ---> ISA Server----> router----> WAN. LAN: > 192.168.0.x ISA: internal NIC 192.168.0.7, External NIC > 192.168.1.250 Router: 192.168.1.100 I presume you have the OpenVPN client and servers on the LAN side, as you didn't say anything else. The client or server side LAN needs to change IP addresses to a separate segment. F.ex. client side to become 192.168.10.0/24 ... this is to avoid routing issues later on. Then configure a OpenVPN client/server setup, with a a separate segment (say, 10.8.0.0/24) ... and then you add routes for 192.168.0.0/24 and 192.168.100.0/24 in the OpenVPN configs. And that's it. > Please refer to me if am doing anything wrong.. am able to connect > client to server but not Network to Network. You most likely are missing proper routes, network segment conflicts (192.168.0.0/24 on both client and server side LAN), firewalling issues on the OpenVPN servers (not allowing traffic to be forwarded between LAN and VPN) or that IP forwarding in general haven't been enabled (in Linux or BSD: sysctl net.ipv4._ip_forward). You might also find this info relevant: <https://community.openvpn.net/openvpn/wiki/BridgingAndRouting#Usingrouting> kind regards, David Sommerseth > -----Original Message----- From: David Sommerseth > [mailto:ope...@to...] Sent: Tuesday, September 18, > 2012 3:30 PM To: C.I.G IT SUPPORT Cc: > ope...@li... Subject: Re: [Openvpn-users] > site to site vpn > > On 18/09/12 13:35, C.I.G IT SUPPORT wrote: >> Hello Everybody, > > > >> Can anybody assist me to create a site to site ovpn.. > > > You got a pretty good starting point when you asked last time: > > <http://thread.gmane.org/gmane.network.openvpn.user/33533> > > It's pretty much the same approach. Other than that, learning how > to configure OpenVPN will pretty much save you a lot of time later > on. Start here: > > > <http://openvpn.net/index.php/open-source/documentation/miscellaneous/static > > - -key-mini-howto.html> > > And then continue here to add PKI (SSL certificates) > > <http://openvpn.net/index.php/open-source/documentation/howto.html#pki> > > And read the man page, which is also available here: > > <http://openvpn.net/index.php/open-source/documentation/manuals/> > > It describes quite well most of the options you need to set up a > site-to-site tunnel. > > Other than that ... try to make use of TUN devices (not TAP) and > UDP for transport, that will give you the best performance on the > tunnel. > > > > kind regards, > > David Sommerseth > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBYb3YACgkQDC186MBRfrruvQCfaK+fUKzsprtQJzKNcPDgh8Ih vBgAoIV7m4JePrHTauAMhlUMp+R+HDnJ =dNT+ -----END PGP SIGNATURE----- 

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/09/12 13:50, Samuli Seppänen wrote: > The OpenVPN community project team is proud to release OpenVPN > 2.3_beta1. It can be downloaded from here: > > <http://openvpn.net/index.php/open-source/downloads.html> > > This release includes several bugfixes, cleanups and minor > enhancements. In addition, the Windows installers comes with an > updated version of openvpn-gui. A full list of new features and the > changelog is available here: > > <https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23> > > A full list of new features and the changelog are available here: > > <https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23> With this release the development phase for OpenVPN v2.4 has started. We will now begin to review and apply patches to the master branch for the next version. So please feel free to review and discuss patches which you feel need attention on the openvpn-devel mailing list. The v2.3_beta1 release will also continue to be developed, but in the beta/2.3 branch on openvpn-testing.git. When the beta releases have stabilised and final bugs have been squashed, we will consider if it's needed to have a release candidate cycle or if we will release it as the final v2.3. So please give the v2.3_beta1 release a good round of testing, report bugs, send fixes if you're able to fix stuff ... and we will hopefully reach a stable version within as few months as possible. kind regards, David Sommerseth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBTTNUACgkQDC186MBRfrptfQCfY817S0L/dPVsnJBD/NduedQL WvkAoJ/PmI9fGE5Cg9xGat+6bs/X8H2D =c2DE -----END PGP SIGNATURE----- 

The OpenVPN community project team is proud to release OpenVPN 2.3_beta1. It can be downloaded from here: <http://openvpn.net/index.php/open-source/downloads.html> This release includes several bugfixes, cleanups and minor enhancements. In addition, the Windows installers comes with an updated version of openvpn-gui. A full list of new features and the changelog is available here: <https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23> A full list of new features and the changelog are available here: <https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn23> The changelog is also attached to this email. For generic help use these support channels: - Official documentation: <http://openvpn.net/index.php/open-source/documentation/howto.html> - Wiki: <https://community.openvpn.net> - Forums: <https://forums.openvpn.net> - User mailing list: <http://sourceforge.net/mail/?group_id=48978> - User IRC channel: #openvpn at irc.freenode.net Please report bugs and ask development questions here: - Bug tracker and Wiki: <https://community.openvpn.net> - Developer mailing list: <http://sourceforge.net/mail/?group_id=48978> - Developer IRC channel: #openvpn-devel at irc.freenode.net (requires Freenode registration) -- Samuli Seppänen Community Manager OpenVPN Technologies, Inc irc freenode net: mattock 

Hi Nelson, Nelson Teixeira wrote: > Hello, > > Sorry by writting directly to devel list, but I'm not being able to > solve this problem I'm in and thought maybe you would be so kind to > take a look. Thanks in advance :) > > I'm having trouble in finding how to end openvpn programmatically in > windows. If I run openvpn in command line, I can end it graciously > with F4. What I want to do is to make my python program (or batch > file/executable program, can be in C/C++) do the same thing: end it > gracioulsy, allow for openvpn to do it's cleanup tasks. > Yet the only thing available to stop the process is taskkill /F /PID > <PID_NUMBER> that ends it immediately without allowing openvpn to do > it's cleanup tasks. If I don't use /F switch, it just ignores the > command. I tried also with /T (Tree Kill). No luck. > I also tried to get openvpn pid and send it a signal using this python > code (it's python but it's easily understandable by anyone: > the "proper" way to do this is to use the management interface; the openvpn-gui code does just that (file openvpn.c): 725 /* Construct command line */ 726 _sntprintf_0(cmdline, _T("openvpn " 727 "--config \"%s\" %s --service %s 0 --log%s \"%s\" " 728 "--management 127.0.0.10 %hd stdin --auth-retry interact " 729 "--management-hold --management-query-passwords --tls-exit"), you can then use the same management interface to properly shut down openvpn again. HTH, JJK 

Hello, Sorry by writting directly to devel list, but I'm not being able to solve this problem I'm in and thought maybe you would be so kind to take a look. Thanks in advance :) I'm having trouble in finding how to end openvpn programmatically in windows. If I run openvpn in command line, I can end it graciously with F4. What I want to do is to make my python program (or batch file/executable program, can be in C/C++) do the same thing: end it gracioulsy, allow for openvpn to do it's cleanup tasks. Yet the only thing available to stop the process is taskkill /F /PID <PID_NUMBER> that ends it immediately without allowing openvpn to do it's cleanup tasks. If I don't use /F switch, it just ignores the command. I tried also with /T (Tree Kill). No luck. I also tried to get openvpn pid and send it a signal using this python code (it's python but it's easily understandable by anyone: import ctypes PROCESS_TERMINATE = 33 handle = ctypes.windll.kernel32. OpenProcess(PROCESS_TERMINATE, False, <PID>) ctypes.windll.kernel32.TerminateProcess(handle, -1) ctypes.windll.kernel32.CloseHandle(handle) I tried all signals ranging from 0 to 33. None did the job. Some are plainly ignored, some terminate the processe forcefully. A colleague of mine remembered that openvpn-gui does it the right way. I'm also a c/C++ programmer, so I grab the source-code and try to find how it does the trick, but I find it's a bit more hidden than I thought. As far as I understood, the disconnect button calls the StopOpenVPN funcion, which sets the o.cnn[config].connect_status field to DISCONNECT*ING * and WatchOpenVPNProcess function tracks it and then disconnects. But if i'm groking this right, the only thing it does besides setting connect_status to DISCONECT*ED* is the following command: SendMessage(o.cnn[config].hwndStatus, WM_CLOSE, 0, 0); Just closing the window, finishes it graciously ? why ? Am I missing the point here ? Can you please tell me how you do the trick ? If anyone else has some idea, I'll love to read it. Thanx, -Nelson 

 Hi All, I have one PC on which  OpenVpn server is  running and 3 MIPS based embedded devices  on which OpenVpn clients are running. They all are connected using Ethernet Gigabit switch. All devices are running on Linux. I stream video to all the 3 devices from the PC using VPN. If i stream data at 50Mbps,  2 devices are working fine. But 3rd device is equipped with slightly low end processor and this device  restarts. But this device works fine if  I stream  at 35 Mbps. Is there any way i can configure OpenVpn server in such a way that it can stream data at 50 Mbps to the first 2 devices and at 35 Mbps to the 3rd device.  Can I use "-shaper n" option to limit the bandwidth. Please help me. HW Configurations -------------- 1 )PC         Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz         RAM - 4 GB         Linux :-  Centos - 5         OpenVpn :- openvpn-2.1.1 2) Embedded Device     Core :-  MIPS 800 Mhz     RAM - 256 MB     Linux - 2.6.29.2     OpenVpn :- openvpn-2.1.1 3) Embedded Device     Core :-  MIPS 600 Mhz     RAM - 256 MB     Linux - 2.6.29.2     OpenVpn :- openvpn-2.1.1 OpenVpn Server Configuration ----------------------------- # IMPORTANT: For comments on any of the setting below, please #            read server.conf.README file server  192.168.0.0 255.255.0.0 port    1194 ca                  /opt/cert/internal/abc.chain cert                /opt/cert/internal/abc.cer key                 /opt/cert/internal/abc.key askpass            /opt/cert/internal/abc.pwd dh                    /opt/etc/openvpn/2.0/keys/dh1024.pem log-append         /var/log/openvpn.log status                /opt/var/log/openvpn.status proto                 udp dev                   tun ifconfig-pool-persist ipp.txt 3600 topology              subnet max-clients           65532 keepalive             10 120 cipher                AES-128-CBC script-security       3 verb                  4 mute                  1 ----------------------------------------------------------------------- Please let me know if more data is required. Thanks and Regards Raj Kumar S

On 11/09/12 17:34, David Sommerseth wrote: > From: Heiko Hund <hei...@so...> > > With this option, users can basically undo the changes of the UTF-8 > support commit 5e86fd93779482b90a191f929edebe414cd78a4f. It's here for > short term compatibility and should be removed again as soon as possible. > > When OpenSSL is used, the subject strings will be in the proprietary > format again. Generally username, X.509 CN, and X.509 subject will again > be subject to '_' replacemant, unless the "no-remapping" flag is > also specified. That flag ensures compatibility with setups using the > --no-name-remapping option, that has been removed in 2.3. > > [v2: More comments related to compat_flags() added by DS plus using > COMPAT_FLAG_QUERY expclit] > [v3: Improved the man page entry for --compat-names, after suggestions > from Bernhard R. Link] > > Signed-off-by: Heiko Hund <hei...@so...> > Signed-off-by: David Sommerseth <da...@re...> > --- > doc/openvpn.8 | 52 ++++++++++++++++++++++++++++++++++++ > src/openvpn/misc.c | 21 +++++++++++++++ > src/openvpn/misc.h | 6 +++++ > src/openvpn/options.c | 10 +++++++ > src/openvpn/ssl_verify.c | 54 +++++++++++++++++++++++++++++++------- > src/openvpn/ssl_verify_openssl.c | 12 +++++++++ > 6 files changed, 146 insertions(+), 9 deletions(-) Applied to master. commit e7412ca3eee2f2a2fb0af5acbe968137cfd7e995 Author: Heiko Hund <hei...@so...> Date: Tue Sep 11 17:34:24 2012 +0200 Add --compat-names option Signed-off-by: Heiko Hund <hei...@so...> Signed-off-by: David Sommerseth <da...@re...> Acked-by: Gert Doering <ge...@gr...> Acked-by: David Sommerseth <da...@re...> Message-Id: 134...@us... URL: http://article.gmane.org/gmane.network.openvpn.devel/7053 kind regards, David Sommerseth 

Hi, On Tue, Sep 11, 2012 at 05:34:24PM +0200, David Sommerseth wrote: > From: Heiko Hund <hei...@so...> > > With this option, users can basically undo the changes of the UTF-8 > support commit 5e86fd93779482b90a191f929edebe414cd78a4f. It's here for > short term compatibility and should be removed again as soon as possible. ACK. Reviewed, and looks good. Have not actually test-compiled and run it as I do not have client certificates in place that contain UTF-8 or other funny characters - but I trust Heiko to have seen enough of that in his environment :-) (I *do* think that the bit-shifting in compat_flags() is "slightly" overengineered, but programmers have the tendency to invest lots of brains and some code into saving a single bit... :-) - it will do the job, though, so no need to spin a v4 for that) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany ge...@gr... fax: +49-89-35655025 ge...@ne... 

On 09/09/12 03:30, David Sommerseth wrote: > From: David Sommerseth <da...@re...> > > When the server is configured with UDP and --push statements, reconnecting > often fails by the client never receiving PUSH_REPLY. The client sends > PUSH_REQUEST and the server logs these requests but does not send them. > > This bug got introduced in commit ff65da3a230b658b2c1d52dc1a48612e80a2eb42 > which tries to avoid sending duplicated PUSH messages if the client/server > connection is slow. > > This patch keeps this behaviour, but instead of a session wide PUSH_REPLY > block it sets an expiry time for the PUSH_REPLY block. The expiry time > is set to 30 seconds. > > Signed-off-by: David Sommerseth <da...@re...> > Cc: James Yonan <ja...@op...> > --- > The solution here probably isn't the optimal fix, as the PUSH_REPLY block > should be reset when the client confirms the connection is established. > However, resetting the context's sent_push_reply variable turned out to > be tricky, as it already was set to '0' on places it would be natural > to reset it. However, it was always '1' in process_incoming_push_msg(). > > Going for the timeout solution is a quick-fix as we need to have this > issue solved before the 2.3 beta releases. If anyone have a better > solution, please submit a patch and we can drop this one. > > To trigger this bug and to test this fix, configure a UDP enabled server > with PKI (--tls-{client,server}, --key, --cert, --ca, etc) and with add > some --push statements as well. When the initial connection has been > established, stop the openvpn client and reconnect. The bug will result > in server receiving and ignoring PUSH_REQUEST and the client will send > these requests until stopped. The result is that the connection cannot > be re-established. Two workarounds have been identified for this > behaviour. A) Add --explicit-exit-notify to the client config, > or B) switch from UDP to TCP. I did not manage to reproduce this on > a single computer running both client and server, but running on separate > computers over the Internet made it possible to trigger this issue. > > src/openvpn/openvpn.h | 2 +- > src/openvpn/push.c | 7 +++++-- > 2 files changed, 6 insertions(+), 3 deletions(-) Applied to master. commit 5d4f5435a421299ed047485d8d99bdf9a0d22fd1 Author: David Sommerseth <da...@re...> Date: Sun Sep 9 03:30:46 2012 +0200 Fix reconnect issues when --push and UDP is used on the server Signed-off-by: David Sommerseth <da...@re...> Cc: James Yonan <ja...@op...> Acked-by: Gert Doering <ge...@gr...> Acked-by: James Yonan <ja...@op...> Message-Id: 134...@us... URL: http://article.gmane.org/gmane.network.openvpn.devel/7044 kind regards, David Sommerseth 

On 11/09/12 13:56, Gert Doering wrote: > We used to call "ifconfig tun0 inet6 add...". The "inet6" part is optional, > and not understood by busybox. So now we call "ifconfig tun0 add ...", > which works on all supported Linux variants. > > Tested on Gentoo, RHEL5+, Debian Lenny & up. > > Signed-off-by: Gert Doering <ge...@gr...> > --- > src/openvpn/tun.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) ACK. Applied to master. commit cae102ae0c2ff934c456cd584cbf87a33cd95206 Author: Gert Doering <ge...@gr...> Date: Tue Sep 11 13:56:55 2012 +0200 make "ipv6 ifconfig" on linux compatible with busybox ifconfig Signed-off-by: Gert Doering <ge...@gr...> Acked-by: David Sommerseth <da...@re...> Message-Id: 134...@gr... URL: http://article.gmane.org/gmane.network.openvpn.devel/7052 Signed-off-by: David Sommerseth <da...@re...> kind regards, David Sommerseth 

On 10/09/12 16:39, Arne Schwabe wrote: > Commit 4806cc102655f1a829d656f6deb83e5953c5eab2 fixed only part of > the problem. Since it removed the filename either the magic filename > has to be resurrected or all checks against priv_key_file need to > take to check for MF_EXTERNAL_KEY as well. This patch implements the > extra checks > > Signed-off-by: Arne Schwabe <ar...@rf...> > --- > src/openvpn/options.c | 25 ++++++++++++++++++++++++- > 1 file changed, 24 insertions(+), 1 deletion(-) ACK. Applied to master. commit 6dad4f8e924086333d32122432f316a17ae67987 Author: Arne Schwabe <ar...@rf...> Date: Mon Sep 10 16:39:33 2012 +0200 Add checks for external-key-managements Signed-off-by: Arne Schwabe <ar...@rf...> Acked-by: David Sommerseth <da...@re...> Message-Id: 134...@rf... URL: http://article.gmane.org/gmane.network.openvpn.devel/7046 Signed-off-by: David Sommerseth <da...@re...> kind regards, David Sommerseth 

On 03/09/12 14:16, Arne Schwabe wrote: > --- > doc/openvpn.8 | 4 ++++ > 1 file changed, 4 insertions(+) Applied to master. commit 341e6bb67f072731d75769ce875633e544544062 Author: Arne Schwabe <ar...@rf...> Date: Mon Sep 3 14:16:04 2012 +0200 Document that keep alive will double the second value in server mode and give a short explanation why the value is chosen. Acked-by: Gert Doering <ge...@gr...> Message-Id: 134...@rf... URL: http://article.gmane.org/gmane.network.openvpn.devel/7041 Signed-off-by: David Sommerseth <da...@re...> kind regards, David Sommerseth