Re: openvpn: actually works?

[Greg Troxel <gdt%lexort.com@localhost>]

Stephen Borrill <netbsd%precedence.co.uk@localhost> writes:

First, my mysterious bad connections were due to the rover being, at the
moment, using IPv6 while being behind a v6-in-v4 tunnel, where the gif
was set to 1280 (NetBSD default).  Changing the openvpn tun-mtu fixed
that, and then I set the the tunnel to 1480.

So my only remaining mystery is "the /24 route (for the rover subnet)
seems to randomly go missing on openvpn restart, sometimes".  Plus
various "MTU issues are hard", including "npf doesn't do ressembly".

>>  How often do you find yourself on a network where openvpn 1194 is
>>  blocked, but other things worked?
>
> Quite a lot, I do a lot of work in schools!

Thanks for the data point.   I will keep that in mind.

>>  Have you set up proxying over 443, which tends not to be blocked?
>
> Yes, I have set it up on 22, 443 and 1935 (some Windows media port)
> based on an outbound port scan. 443 is often blocked, but it does
> usually work through a proxy.

I guess that's CONNECT so your e2e is ok.

> However as an OpenVPN instance cannot do both UDP and TCP and
> client-to-client uses routing within the instance, a TCP connection
> doesn't work as well in my scenario as I lose access to the other
> clients.

With just rovers, I'd expect this to be ok, but thanks for the caution.