Re: [Openvpn-users] multiple --remote parameter didn't work as expected (by me)

[James Yonan <jim@xxxxxxxxx>]

On Wed, 6 Apr 2005, Claas Hilbrecht wrote:

> Today I tried to start using the multiple "--remote" parameter option from 
> OpenVPN for some more clients. I noticed some unexpected behaviour (at 
> least to me unexpected).
> 
> First off all I tried a setup with the following entries:
> 
> rport 10193
> remote 83.213.243.31
> remote 217.24.217.139
> remote 193.14.45.6
> remote 143.245.43.151
> 
> The "--float" parameter is not set since all possible peers have fixed IP 
> adresses and all are listed as possible remotes. After starting OpenVPN I 
> get this message from OpenVPN:
> 
> 1112795170,N,TCP/UDP: Incoming packet rejected from 
> 143.245.43.151:10193[2], expected peer address: 193.14.45.6:10193 (allow 
> this incoming source address/port by removing --remote or adding --float)
> 
> As the notice suggested adding "--float" will fix this but on the other 
> hand giving multiple peers with "--remote" should work too I think.

This is exactly what I would expect.  Without --float, the OpenVPN client 
will only accept packets from the current server in the remote list.

Probably in your test, you are starting and stopping the client, and when
you start the client again, it may connect to a different server than the
last connection, but the old server is still sending ping packets (on the
same port # if --nobind isn't used on the client), so these packets will
be dropped with the above message.

If you added --float, the packets would still be dropped, but without 
warning.

> The next thing is that some peers are unreachable (to test the --remote 
> option). OpenVPN gives the message:
> 
> >LOG:1112795310,N,read UDPv4 [EHOSTUNREACH]: No route to host (code=113)
> 
> I think OpenVPN could give up the connection attempt immediately if 
> multiple peers are given and a network error occurs.

That's an interesting thought -- the concern is that this might cause a 
lot of churning between different servers since even minor, non-fatal 
network errors would then trigger a switch.  You would need to be sure 
that short-term network outages would only result in dropped packets, not 
any explicit ICMP error returns -- otherwise, the effect would be the same 
as a very low keepalive timeout.

And most people will want a keepalive timeout large enough that
short-term network outages of a few seconds don't trigger a restart.  You
don't want to needlessly churn too much through your server list, because
in most cases, connecting to a new server also means that you will be
getting a new TUN/TAP address, which means the TUN/TAP interface must be 
cycled, which means that connections over the tunnel will be reset.

> The "--remote-random" option seems to work as stated in the manual but the 
> randomness is "low". I've started OpenVPN 10 times and the first host tried 
> 8 times is 83.213.243.31. I know that get_random() is used to obtain 
> randomness but it seems "strange" to me.

Randomness is strange by definition, especially with small sample sizes :)

The randomness is coming from prng_bytes in crypto.c which should be 
producing crypto-grade randomness (I would be seriously worried if it 
wasn't).

My testing (on Linux 2.6) shows that over large sample sizes, the output
of prng_bytes is well distributed.

The theoretical probability that a randomly chosen 10 digit base 4 number 
would have at least 8 digits of the same value is 1 in 601.2477064220 
(which is equivalent to your scenario).

I did an empirical test on get_random modulo 4 and found that with 100,000 
iterations each, the number of tests which show the anomaly is:

count=100000 anomaly=170
count=100000 anomaly=148
count=100000 anomaly=174
count=100000 anomaly=166
count=100000 anomaly=175
count=100000 anomaly=133
count=100000 anomaly=159
count=100000 anomaly=184
count=100000 anomaly=156

As the number of tests approaches infinity, the anomaly mean should
converge on the theoretical mean of 166.3208007812, which it appears to be
doing in a limited number of tests.

So I'm not too worried about this, however if your tests show that this
anomaly comes up an order of magnitude more frequently than 1 in 601
trials, it could mean that your system not only lacks sufficient entropy,
but that OpenSSL is not detecting this.  OpenVPN always checks the return
status of RAND_bytes to ensure than OpenSSL has sufficient entropy at its
disposal.  OpenVPN would crash with a fatal error message if the
RAND_bytes return indicated insufficient entropy.

> And one feature request. It would be nice if the managment console could 
> set a host to connect to. The idea behind this is to remove 
> "--remote-random" and start the OpenVPN process in "hold" mode. Now you can 
> select a host to connect to with the management console and release the 
> "hold". This would be useful if you connect to serveral clients with the 
> same configuration via ISDN to make some maintaince.

Can you submit a patch for this?

James

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users