-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/03/2011, David Sommerseth wrote:
> Sorry that you haven't received any response quickly. Most of us
> here are having full time jobs which is not directly related to
> OpenVPN.
I'm sorry if I sounded like I felt that answers were slow in coming.
Actually, I was amazed with the response time to my initial
submission. When the rhythm of the discussion dropped, I thought
people were losing interest, that's why I asked.
> None of these products supports network device name for setting up
> listen addresses. I chose these products as they are all aimed at
> being accessed from the "wild Internet", accepting connections from
> whoever who are not necessarily known to the server. Which makes
> their use cases closer to OpenVPN.
The reason I looked into this in the first place was that, unlike
those TCP-based protocols, I couldn't get OpenVPN to work on a
firewall with two external IP addresses without running two deamons,
each one bound to one interface only. It is then that I stumbled upon
the difficulty of setting up the server that must listen on an
interface that has a dynamically-assigned address.
> But to summarise it somehow, based on my pondering ... a quick
> pro/cons list:
> + makes config easier for sys-admins
> - OpenVPN will only listen to the first identified IP address,
> which will need to be both IPv4 and IPv6 aware. This will
> become a support issue pretty quickly.
Actually, that would require a user to *both* have multiple IP
addresses on the same interface, *and* to want to use this feature,
which I'd gather is not likely. In any case, a short mention in the
documentation that the "if:" notation only works with interfaces that
have just one interface would solve it (I can even add code to check
for this condition and log a warning). This of course, would only be
the case until OpenVPN supports listening on multiple addresses, then
we can simply fix it.
> - 6 different open source products which has a similar usage
> profile (open access from the Internet) do not have this support.
Those protocols aren't affected by the issue I mentioned, and I'd
venture to say that they are not nearly as likely to be used in a
dynamic-IP address setup as OpenVPN, which is great for tunnelling
into home.
In any case: I didn't tackle this because I was bored, but because I
have a real use case, and a working setup, which I think other people
may find useful.
> - Can cause some surprises, if people re-plug a network cable
> between two network devices. Suddenly OpenVPN is available on a
> network segment it should not be available on, due to not being
> restricted to particular a IP address. Of course it should be a
> firewall stopping it in front, but that might have been disabled as
> well - for unknown reasons. Surely this is a PEBKAC issue, but
> they do happen more often than we like to admit.
Sure... but such a problem would:
1) be rather quickly discovered, when people cannot connect to the
VPN,
2) be rather unlikely to cause security issues, since even
from the wrong network, people would need the credentials to
get connected.
Fede
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iD8DBQFNeun1bPULDL0CxuARAtSsAJ9DFnb8SFs/Gd0Am9/A9IRKpui6LACg1/aw
lif+92pajziWM1/x41kRbhA=
=N/8A
-----END PGP SIGNATURE-----
