Re: openvpn: actually works?

[Stephen Borrill <netbsd%precedence.co.uk@localhost>]

On Tue, 1 Apr 2025, Greg Troxel wrote:
> A long time ago I set up openvpn servers on a few systems, so I could
> use the android client to get non-broken internet (at places that think
> blocking random ports like xmpp is useful and courteous to guests).  For
> many years this was basically ok.
>
> My setup has been UDP, and tun.  The authentication setup is
> unreasonable but I have that part ok.  Everything today is NetBSD 9;
> this is part of getting everything in order prepartory to updating to
> 10.
>
> I have NAT set up from prefix/24 to the global IP address of the machine
> (a mix of ipfilter and npf).  I'm only, so far, trying to do v4.
>
> Now I'm trying again after ignoring it for a year, and have found:
>
>  1) Sometimes, it seems like a client gets an address that isn't
>  $client_prefix.2, and routing does not work right.  The combination of
>  tun being configured as point-to-point and the installed routes seems
>  off.  I see
>
>    tun0: flags=0x8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
>            inet 10.0.16.1/24 -> 10.0.16.2 flags 0x0
>    10.0.16/24       10.0.16.2        UGS         -        -      -  tun0
>    10.0.16.1        tun0             UHl         -        -      -  lo0
>    10.0.16.2        10.0.16.1        UH          -        -      -  tun0
>
>  and ping to 10.0.16.7 gets no route to host.   It seems tun should be
>  in subnet mode, not p2p, separately from ip vs ethernet (tun vs tap),
>  or at least a subnet route should be added.  On a different system
>  where the routing tables look similar, things are ok.
>
>  I think I traced this down to the subnet route going missing.
>  Stopping openvpn, destroying the tun, and restarting:
>
>    10.0.17/24       10.0.17.2        UGS         -        -      -  tun0
>
>  The question remains as to why the subnet route points to .2.  But now
>  that machine works ok.
>
>  2) Connections to most places work ok, but I found that on one server,
>  https connections to a non-openvpn-related https server, on the vpn
>  server, with the same IP address, were failing, and tcpdump on tun0
>  showed syn, syn/ack, ack, and then a packet with 1300:1700 ish from
>  the client, leading to an ack of the syn.  The first packet is
>  missing.  Changing to TCP made this work, it seems.  But TCP in TCP
>  isn't really a great thing.
>
> I know I have more debugging to do.  I know I should look at wireguard,
> despite that being harder on netbsd9.
>
> I'm really writing to ask "are you using openvpn and is it working or is
> it not".

I use OpenVPN on -9 with Windows, NetBSD and Android clients all without 
any problem. I do use persistent ip pools:
ifconfig-pool-persist persist-pool

and client-to-client configs which leads to a certain amount of pushing of 
routes.

client-config-dir ccd
client-to-client

route 192.168.10.0 255.255.255.0
push "route 192.168.10.0 255.255.255.0"

Then I have iroutes in ccd/clientname (based on the certificate)

> Other questions:
>
>  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!

>  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.

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.

--
Stephen