Thanks for the comments! A couple thoughts / questions, below. ... Russell
-----Original Message----- From: David Sommerseth [mailto:[email protected]] Sent: Friday, July 7, 2017 8:00 AM To: Morris, Russell <[email protected]>; [email protected] Subject: Re: [Openvpn-users] Intermittent Connectivity On 06/07/17 19:07, Morris, Russell wrote: > Hi, > > OK, pulling my hair out with this. I haven't really seen this before, > but having issues with intermittent connectivity (lately, also with > the latest versions of OpenVPN). I noticed it over SSH (connection > seems to hang for periods of time), so then I tried ping => results > below, and quite interesting (and very variable). > > In case someone asks - I am running over TCP, but have never seen this > before (so I'm not sure that's really the issue). I did try connecting > to a second machine (different location) ... and that seems OK (but > it's running TUN, vs. TAP - part of the issue?). > [...snip...] > Thoughts? Things to try? This looks like a typical wacky connection between client and server. And using --proto tcp with wacky connections, things tends to get ugly quickly. And especially when sending TCP packets inside the tunnel. That results in a lot of "resend this packet" requests both on the inside and outside of the tunnel. So try switching to --proto udp. [R. Morris] Actually, is it really TCP? Asking because the other connection I tested is TCP also, just TUN instead of TAP ... and it's rock solid. I don't really have the option to use UDP, a bit handcuffed there ... :-(. > And yes, I do need TAP, as I need to bridge onto the subnet (to access > different machines remotely). "to access different machines remotely" is very seldom a good argument for bridging. If your remote machines understands TCP/IP routing properly, you will most likely have a far better result using a routed TUN setup, with the VPN link (tun adapters) residing in their own subnet. This will remove a lot of broadcast traffic, which can eat up the bandwidth - especially there's lots of broadcast chatter on both sides of the tunnel. Plus the packets transported between the VPN client and server is also a bit smaller, as it doesn't need the Ethernet frame (which contains MAC addresses among others). Those scenarios where bridging really makes sense are for non-TCP/IP protocols or where the application protocol really depends on broadcast traffic (like older LAN games). If you think of Windows file shares, it is far better to use WINS, which works very well over routed TUN. [R. Morris] Intrigued ... :-). TUN would be fine, if I could get to the machines on the subnet ... but can I really? I need to run RDP, VNC, SSH, etc. How is routing handled with TUN? Again, I'm interested to try this, but I thought to be "on" the subnet, and access all the machines (by name) I needed to use TAP. -- kind regards, David Sommerseth OpenVPN Technologies, Inc ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-users
