I should have elaborated a bit more. There are usually properly routed
solutions for anything you need to do. There are exceptions, like some old
networked video games.
Network file shares and such have options like WINS and DNS for service
discovery.
Eric Crist
> On Nov 9, 2017, at 7:22
If you want bridging, you probably don’t know what you’re doing.
Eric Crist
> On Nov 9, 2017, at 12:23 PM, Rajyaguru, Chirag (GE Digital)
> wrote:
>
> Hi Daniel,
>
> I think you are looking for Bridging not routing and thus use
>
On 09/11/17 11:08, Gof via Openvpn-users wrote:
> As to port sharing, I can disable it, but isn't it used only during initial
> handshake?
Port sharing is a feature for the server side to "hide" OpenVPN behind
an existing SSL/TLS based service (typically https). So packets which
carries an
Hi Daniel,
I think you are looking for Bridging not routing and thus use
https://community.openvpn.net/openvpn/wiki/OpenVPNBridging
Thanks,
Chirag
On 11/9/17, 10:20 AM, "Daniel Miller via Openvpn-users"
wrote:
I'm probably misunderstanding the
Hi,
On Thu, Nov 09, 2017 at 10:19:27AM -0800, Daniel Miller via Openvpn-users wrote:
> I'm probably misunderstanding the purposes of things, but...
>
> I have a Linux VPN server and a Windows client. I want the client to be
> able to see at an "arp" level all the server-side LAN devices. At
Hi,
On Thu, Nov 09, 2017 at 01:21:56PM -0500, Selva wrote:
> So I do feel that high latency under load is not a fundamental limitation
> -- probably
> openvpn with --proto tcp is not trying hard to manage the queue smartly?
It isn't. It's just stuffing packets into the tcp stream as they come
On 10/11/17 02:19, Daniel Miller via Openvpn-users wrote:
> I'm probably misunderstanding the purposes of things, but...
>
> I have a Linux VPN server and a Windows client. I want the client to be
> able to see at an "arp" level all the server-side LAN devices. At the
> moment, I'm using a
Hi,
On Thu, Nov 9, 2017 at 11:48 AM, Gregory Sloop wrote:
> Top posting
>
>
>
>
>
>
>
> *JJK> The only thing you can do, is to run something like Traffic Control
> (tc) JJK> on the link to prioritize low latency traffic compared to bulk
> JJK> downloads. If I throttle my iperf
I'm probably misunderstanding the purposes of things, but...
I have a Linux VPN server and a Windows client. I want the client to be
able to see at an "arp" level all the server-side LAN devices. At the
moment, I'm using a routed (tun) connection. The server LAN and the
client LAN are
Hi,
On Thu, Nov 09, 2017 at 08:48:45AM -0800, Gregory Sloop wrote:
> So, the fact that OpenVPN does similar things seems unremarkable to me.
> [But perhaps I missed something more in the thread that does make it more
> remarkable...]
The original question was "why does this happen for openvpn
Top posting
JJK> The only thing you can do, is to run something like Traffic Control (tc)
JJK> on the link to prioritize low latency traffic compared to bulk
JJK> downloads. If I throttle my iperf session to use 80% of the maximum link
JJK> speed then the ping times remain much lower. When the
Hi,
On 09/11/17 18:08, Gert Doering wrote:
On Thu, Nov 09, 2017 at 05:19:14PM +0100, Jan Just Keijser wrote:
- without any load the ping times are ~ 7 ms , which is actually quite
good for ADSL
- when I run a long iperf session and then do a ping in the background,
the ping times go up to
Hi,
On Thu, Nov 09, 2017 at 05:19:14PM +0100, Jan Just Keijser wrote:
> - without any load the ping times are ~ 7 ms , which is actually quite
> good for ADSL
> - when I run a long iperf session and then do a ping in the background,
> the ping times go up to 800+ ms, then once the iperf is
Hi,
On 09/11/17 11:08, Gof via Openvpn-users wrote:
you're using bridging + tap + proto tcp + port sharing on a VPS and are
expecting good latency? hmmm there are many reasons why that combination
will NOT give you any performance.
Bridge is used only to link TCP and UDP clients. All
Hi again,
Thanks for all responses.
Selva:
> In case it helps: I recall seeing long latency with TCP tunnels under load.
> But don't have any TCP tunnels in real use, so never looked more into it.
Thanks, at least it shows it's not something related to my setup...
Jan:
> you're using
Hi,
On Thu, Nov 09, 2017 at 01:16:39AM +0100, Jan Just Keijser wrote:
> Admittedly, not as much as you are seeing but it's definitely there and
> it is to be expected over a VPN link: during the transfer/throughput
> test the VPN is encrypting+decrypting like mad, which will affect
> latency
16 matches
Mail list logo