Hi Henno,
Henno Täht wrote:
Hello!
2010/7/2 David Sommerseth <openvpn.l...@topphemmelig.net
<mailto:openvpn.l...@topphemmelig.net>>
On 02/07/10 19:38, Henno Täht wrote:
> Hello!
>
> Can anyone experienced and helpful scribble a little guide how
to have
> the same OpenVPN server listening both on 1194 UDP (reason: fast,
> preferable) and 443 TCP (reason: always works, fallback)?
That is not possible. OpenVPN can only listen to TCP or UDP, not
both.
To do this, you will need two independent OpenVPN configurations and
run two separate OpenVPN daemons
Having that said, this is a common question and a feature which is
under
evaluation for the next generation OpenVPN.
Great news!
A client config file should also support this. Something like this:
remote 198.51.100.15:1194 <http://198.51.100.15:1194> proto udp wait 10
remote 203.0.113.234:443 <http://203.0.113.234:443> proto tcp wait 1
remote 192.168.0.1:8080->203.0.113.234:443 <http://203.0.113.234:443>
proto tcp wait 1
Explanation:
First try direct connection to udp port 1194, wait 10 seconds (should
be enough to survive OpenVPN server restarts after config change).
If that fails (timeout of 10 seconds is past and no answer), try
another ip with tcp 443 and wait 1 second for reply (443 tcp is
usually left open for https).
If that too fails, assume that the user is again visiting NSA-like
institution but which luckily has a local proxy (which allows only for
tcp port 80 and 443 connections for that matter).
This is just some thoughts of me how OpenVPN should treat the --remote
option in the future.
I'm hoping that someone picks this up to start a discussion.
the client side already supports this (with a drawback): if you read the
openvpn 2.1 manual page , section 'connection profiles' you'll see
<connection>
remote host:1194
proto udp
</connection>
<connection>
remote host:443
proto tcp
</connection>
<connection>
remote host:443
proto tcp
http-proxy host:port
</connection>
etc. The drawback is that you can no longer tweak some settings , such
as fragment/tcp timeouts etc. This is an open bug which hopefully will
be addressed in openvpn 2.2 ; the redesign of openvpn to allow multiple
listeners on the server side is further off.
HTH,
JJK
