Closed GoogleCodeExporter closed 9 years ago
In order to support this openvpn itself should emulate persist-tun (this is
essentialy what you are asking for) by comparing last configuration to the
current configuration and if need open a new tun and after that close the
current tun.
Original comment by arne@rfc2549.org
on 29 Aug 2012 at 8:43
This issue was closed by revision 2004a5086a4e.
Original comment by arne@rfc2549.org
on 12 Sep 2012 at 11:42
This does bring the problem closer to a solution, but what happens if the vpn
is never able to connect to the server? A tun device is never created, so
traffic flows freely.
This does however solve the problem for "what happens if the server disconnects
after a TUN device was already created"
Thanks for the quick fix and response
Original comment by dkapuch...@gmail.com
on 14 Sep 2012 at 11:34
I think the normal OpenVPN client behaves in the same way. tun is
created/opened on the first connect
Original comment by arne@rfc2549.org
on 14 Sep 2012 at 11:39
Perhaps all that's needed is for OpenTun to be called right away, regardless of
whether the openvpn client requested a TUN? then, when it does request, pass it
TUN that was provided earlier or open a new one and close the old one?
Original comment by dkapuch...@gmail.com
on 14 Sep 2012 at 11:41
I understand. What we're trying to do is provide the following security feature:
If someone is intentionally (MITM) blocking the connection to our VPN, don't
allow any outgoing traffic to the network.
But for that to happen, we have to have the TUN device created right away, and
not only after a connection was established.
Original comment by dkapuch...@gmail.com
on 14 Sep 2012 at 11:44
Yes I understand what you trying to do. If you for example configure a static
p2p tunnel configuration with no pull options openvpn may directly open the tun
device. Also note that opening the tun with default route set will cause dns
resolution to fail when the tunnel is not connected.
Original comment by arne@rfc2549.org
on 14 Sep 2012 at 11:52
Great, thanks, I hope that will make it work.
Will DNS resolution fail also for the connection to the server? or does
protecting the socket(PROTECTFD) allow the DNS lookup to pass through?
Thanks,
Daniel
Original comment by dkapuch...@gmail.com
on 14 Sep 2012 at 12:12
DNS resolution will fail also for the connection to the server. I am only
proctecting the sockets that openvpn itself creates. Protecting DNS lookup
would mean I have to my own DNS resolver library where I can control the socket
call.
Original comment by arne@rfc2549.org
on 14 Sep 2012 at 1:27
Original issue reported on code.google.com by
dkapuch...@gmail.com
on 29 Aug 2012 at 6:39