Yep, agreed - and have DNS (on the subnet) up and running. Need to follow the instructions in the other email, see if I can get that up and running over TUN.
FYI, I can't send ICMP outside the tunnel - it gets blocked (doesn't get out) ... ☹. Thanks! ... Russell -----Original Message----- From: Jan Just Keijser [mailto:[email protected]] Sent: Friday, July 7, 2017 9:38 AM To: [email protected]; Morris, Russell <[email protected]> Subject: Re: [Openvpn-users] Intermittent Connectivity 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. JJK ------------------------------------------------------------------------------ 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
