[Openvpn-devel] 400 vpn clients 20% of them loosing the route frequently
I have one OpenVPN server version 2.0.2 using TCP port 1194 with TLS with about 400 clients connected to it. From time to time it's impossible to ping the client from the server, but if you log into the client and ping the server, the server now became able to ping the client. I made a lot of tests removing the bridge and trying a older versions of openvpn and the problem still hapenning with about 20% of the clients connected to the vpn. here is the config of the client and server: # SERVER CONFIG mode server port 1194 proto tcp-server dev tap tls-server ca keys/ca.crt cert keys/sauron.crt key keys/sauron.key dh keys/dh1024.pem #tls-auth keys/ta.key 0 #ifconfig 10.100.0.2 255.255.0.0 #ifconfig-pool 10.100.99.50 10.100.99.100 255.255.0.0 server-bridge 10.100.0.10 255.255.0.0 10.100.99.100 10.100.255.254 push "dhcp-option DNS 200.160.255.85" push "dhcp-option DNS 200.160.255.84" push "ping 10" push "ping-restart 60" client-config-dir config client-to-client keepalive 10 120 comp-lzo max-clients 1024 persist-key persist-tun status openvpn-status.log log openvpn.log verb 2 ## # CLIENT CONFIG client tls-client dev tap proto tcp-client #remote-random remote 200.160.255.100 #remote vpn1.vexbr.com.br #remote vpn2.vexbr.com.br rport 1194 lport 9000 resolv-retry infinite persist-key persist-tun mute-replay-warnings float ping 10 ping-restart 60 comp-lzo verb 4 ca keys/ca.crt up ./vexbr.up cert keys/escritorio-claro.crt key keys/escritorio-claro.key # -- Marcelo Toledo
Re: [Openvpn-devel] 400 vpn clients 20% of them loosing the route frequently
Em Ter, 2005-09-27 às 21:58 -0400, Leonard Isham escreveu: > On 9/27/05, Marcelo Toledo wrote: > > I have one OpenVPN server version 2.0.2 using TCP port 1194 with TLS > > with about 400 clients connected to it. From time to time it's > > impossible to ping the client from the server, but if you log into the > > client and ping the server, the server now became able to ping the > > client. I made a lot of tests removing the bridge and trying a older > > versions of openvpn and the problem still hapenning with about 20% of > > the clients connected to the vpn. > > > > here is the config of the client and server: > > > > # SERVER CONFIG > > mode server > > port 1194 > > proto tcp-server > > dev tap > [snip] > > Observations: > 1. 400 clients... 1 server only? Yes, 400 clients and only 1 server. > 2. TAP means additional overhead full ethernet packet encapsulated in > TCP/IP packet. Broadcasts, fragmented ethernet datagrams and for 400 > clients We don't use TUN because from what I know it opens one connection per port and also one configuration per client, which is insane for a 400 clients and growing (we're going to reach 600 by the end of this year). > 3. TCP over TCP is not recommended. The internal congestion control > can conflict with the external congestion control. We already used OpenVPN with UDP, but the oscillations were much higher then today, that's why we migrated to TCP. > 4. What is your full bandwidth and usable bandwidth at the server? We have 3MB and we're using half of it (1.5). what do you think? -- Marcelo Toledo
Re: [Openvpn-devel] Patch: TAP usage made non ARP dependent
Em Seg, 2005-10-03 às 21:43 +0200, Rolf Fokkens escreveu: > Hi, > > Using OpenVPN to build a WAN, I noticed a disturbing thing: After > failing over to secondary OpenVPN server it takes a long time until a > ping to a client side IP works again. I think I know what's happening: > ... great to read it! We're going to test your patch. Thanks a lot. -- Marcelo Toledo
Re: [Openvpn-devel] Patch: TAP usage made non ARP dependent
Em Ter, 2005-10-04 às 14:06 +0200, Rolf Fokkens escreveu: > > So another thing that should be implemented probably is aging. Alright, I am aware. Are you planning working on this? -- Marcelo Toledo
Re: [Openvpn-devel] Patch: TAP usage made non ARP dependent
Em Ter, 2005-10-04 às 20:57 +0200, Rolf Fokkens escreveu: > Marcelo Toledo wrote: > > Em Ter, 2005-10-04 às 14:06 +0200, Rolf Fokkens escreveu: > > > > > So another thing that should be implemented probably is aging. > > > > > > > Alright, I am aware. Are you planning working on this? > > > Attached you'll find find a new patch which includes aging. Could you > try? that's great! I will try it, thanks. -- Marcelo Toledo
Re: [Openvpn-devel] 400 vpn clients 20% of them loosing the route frequently
> What are the stats on the server? Are there any resource issues? > CPU, TCP. etc. Nope, everything ok. > OpenVPN 1.X was one port per connection TUN or TAP. OpenVPN 2.x > supports the old setup, but was designed with a server mode for _both_ > TUN and TAP. You can either dynamically hand out IP addresses or > statically with either method. Good to hear it, we already performed tests with one server and 3 clients, looked ok. Now we're going to install the major server and installing upgrading the clients slowly to see how it goes. > Are these site-to-site or road warriors? Are the 20% always the same > or random? Do the 20% have anything in common. Ant NAT devices or > firewalls in between that may be having periodic resource issues? it is site-to-site. And the 20% are not always the same, they vary a lot. We have firewall but it's not causing the issue. > Have you considered setting up cacti or other system to monitor > resources and provide graphs? Not yet... suggestions? > Consider setting up a second server or OpenVPN instance and use TUN > with UDP and migrate. Did it. > Do you have any packet captures of the traffic out the TAP interface > on the server and client that experiences the failures? Nope. > I don't know your workload or any other details, but what about > another person to take some of your workload so you can concentrate on > this issue. Or a second set of eyes to work on this issue with you (I > would look for someone with at least as much networking experience as > you have). That would be great, actualy I am not looking too much into this, I am just interacting with someone who is actualy doing this, but looks like what you told me will work fine, I will let you know after we have more clients connected. once again, thanks a lot for your time, -- Marcelo Toledo
Re: [Openvpn-devel] Patch: TAP usage made non ARP dependent
Em Ter, 2005-10-04 às 20:57 +0200, Rolf Fokkens escreveu: > Marcelo Toledo wrote: > > Em Ter, 2005-10-04 às 14:06 +0200, Rolf Fokkens escreveu: > > > > > So another thing that should be implemented probably is aging. > > > > > > > Alright, I am aware. Are you planning working on this? > > > Attached you'll find find a new patch which includes aging. Could you > try? We have tested it in two ways: 1. Applied only in the server, worked perfectly with 3 clients. Right now we're going to try few hundreds. 2. Applied the patch only in the client, worked well but they couldn't see each other. Should I apply in both or only in the server is enough? -- Marcelo Toledo
Re: [Openvpn-devel] Patch: TAP usage made non ARP dependent
Em Sex, 2005-10-07 às 18:19 +0200, Rolf Fokkens escreveu: > > Could be a silly question, but to be sure: you had the client-to-client > option enabled on the server side? Yes we do. > The patch should work both on the client and the server, but for clients > it hardly does anything at all. alright, here what we have done. In the main server we installed the patch. We have ~400 clients connected to it, 3 of them we also installed the patch, here is the result. All these 3 clients couldn't see each other but they could see the remaining 397 clients. The 397 couldn't see the 3 clients. I think that's it, any idea? -- Marcelo Toledo
Re: [Openvpn-devel] Patch: TAP usage made non ARP dependent
Em Dom, 2005-10-09 às 13:22 +0200, Rolf Fokkens escreveu: > Attached the patch with #ifdefs. I added a #define MACTAB in > config.h.in, though that may not be the proper way to do it. > > I tested it with and without the #define MACTAB, both ways it compiles > and runs OK with a TAP interface. I didn't test TUN. Hi Rolf, I've tested your old patch and here is the result. Compiling we had a few warnings: In file included from multi.h:40, from mtcp.c:35: mac_table.h:6: warning: redefinition of `uint32_t' /usr/include/stdint.h:52: warning: `uint32_t' previously declared here mac_table.h:7: warning: redefinition of `uint8_t' /usr/include/stdint.h:49: warning: `uint8_t' previously declared here mac_table.c: In function `mactab_init': mac_table.c:72: warning: assignment makes pointer from integer without a cast mac_table.c: In function `mactab_remove_mi': mac_table.c:275: warning: assignment makes integer from pointer without a cast gcc -g -O2 -o openvpn base64.o buffer.o crypto.o error.o event.o fdmisc.o forward.o fragment.o gremlin.o helper.o init.o interval.o list.o lzo.o manage.o mbuf.o misc.o mroute.o mss.o mtcp.o mtu.o mudp.o multi.o ntlm.o occ.o openvpn.o options.o otime.o packet_id.o perf.o ping.o plugin.o pool.o proto.o proxy.o push.o reliable.o route.o schedule.o session_id.o shaper.o sig.o socket.o socks.o ssl.o status.o thread.o tun.o mac_table.o -lssl -lcrypto -llzo -ldl And this error appeared in the server when trying to stabilish a connection. Sat Oct 8 14:28:25 2005 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ] Sat Oct 8 14:28:25 2005 Listening for incoming TCP connection on [undef]:1194 Sat Oct 8 14:28:25 2005 TCPv4_SERVER link local (bound): [undef]:1194 Sat Oct 8 14:28:25 2005 TCPv4_SERVER link remote: [undef] Sat Oct 8 14:28:25 2005 Initialization Sequence Completed Sat Oct 8 14:30:16 2005 Assertion failed at multi.c:1815 Sat Oct 8 14:30:16 2005 Exiting -- Marcelo Toledo
Re: [Openvpn-devel] Re: Patch: TAP & True MAC aging
Em Ter, 2005-10-11 às 21:29 +0200, Rolf Fokkens escreveu: > Hi, > > Attached the latest version of the MAC table patch. This patch allowes > OpenVPN to learn (and importantly forget!) MAC addresses like ethernet > switches. Also (like ethernet switches), OpenVPN now broadcasts packets > with unknown MAC addresses (without the patch these packets are dropped). Hello, sorry the long delay, but we now have tested this new patch. No error appeared but the same situation still persist. Rolf if you would like to schedule we could talk in private to solve this problem, I can even call you if you would like to perform tests, maybe I can try to let you work directly in our environment. Just let me know. -- Marcelo Toledo
