On 07/07/17 16:38, Jan Just Keijser wrote: > Hi, > > On 07/07/17 15:00, David Sommerseth wrote: >> 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. > agreed, but do note that Morris is sending ICMP packets inside the > tunnel - so that rules out some of the TCP-over-TCP badness. > It would be interesting to see the simultaneous ping results *outside* > the tunnel, i.e. between client and VPN server. >>> 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. >> >> > again, I fully agree with David, *BUT* Microsoft has declared WINS to > be dead; it's even so bad that there are DoS holes in the WINS server > that they will not fix; you should switch to DNS/AD style name serving > instead. Thanks! :) As I'm not an active Windows user, I just re-iterate what has been said for many years - and I was not aware of the DoS holes ... no real excuse, but thanks for point that out! I agree DNS/AD is far better though.
-- kind regards, David Sommerseth
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
