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
