[Openvpn-devel] regressions in openvpn 2.4.1

[Farkas Levente]

hi,
after we upgrade our servers and client to 2.4.1 we detect many regressions.

- first was that with this the server no longer works and the server
restart fail after upgrade. imho it's not a safe behavior. but it was
easy to fix at least.
script-security 2 system

- then the new systemd unit files (ie openvpn-server and openvpn-client)
not working. ie if i move all th config file from /etc/openvpn to
/etc/openvpn/server then the server fail to start. and still not found
any other solution then move back the config files. i open a bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1446795

- but the most annoying on is that if the server runs and a client
already connected but reboot the client then in most case it's not able
to reconnect. on the server log we see this error message:

Sun May  7 23:46:57 2017 .. PUSH: client wants to negotiate cipher
(NCP), but server has already generated data channel keys, ignoring
client request
Sun May  7 23:46:57 2017 ... AEAD Decrypt error: cipher final failed
Sun May  7 23:47:02 2017 ... AEAD Decrypt error: cipher final failed

but if i restart the server then everything working perfectly and a the
clients can reconnect.
relevant part of the server config:

proto udp
dev-type tun
dev vpn-udp

remote-cert-tls client
cipher  AES-256-CBC
authSHA256
tls-cipher
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA

topology subnet
client-to-client
comp-lzo no
persist-tun
persist-key
persist-local-ip
keepalive 10 120
push "comp-lzo no"
push "persist-tun"
push "persist-key"

nobody has the same problems?
thanks

-- 
  Levente   "Si vis pacem para bellum!"

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] how to report bug

[Farkas Levente]

hi,
what is the current prefered way to report bug in openvpn?
trac? eg is there any chance to this will be fixed?
https://community.openvpn.net/openvpn/ticket/225
regards.

-- 
  Levente   "Si vis pacem para bellum!"

Re: [Openvpn-devel] Documentation and alternative SSL backend patches

[Farkas Levente]

On 12/02/2010 12:10 PM, Matthias Andree wrote:
> Am 02.12.2010 10:46, schrieb Farkas Levente:
>> On 12/02/2010 10:05 AM, Adriaan de Jong wrote:
>>> Hi List, 
>>>
>>> We've been working on OpenVPN in preparation for a security evaluation. 
>>> This entailed documenting OpenVPN at a relatively high level, removing the 
>>> dependencies on OpenSSL, and adding support for a simpler, easier to 
>>> evaluate library (PolarSSL).
>>>
>>> This was done in a series of patches:
>>> - Patch 1: Adds documentation to OpenVPN through Doxygen.
>>> - Patch 2: Splits out OpenSSL-specific code, defining a clean "backend" 
>>> interface for both the crypto and SSL modules. Splits the SSL module into 
>>> channel setup and verification sub-modules.
>>> - Patch 3: Adds a backend for PolarSSL.
>>>
>>> We'd love to release these patches to the community. Unfortunately, the 
>>> patches are now based on 2.1.4, and need to be rebased to a newer version. 
>>> Before we spend time on updating the patches to the current revision of 
>>> OpenVPN, we'd like to know whether there is an interest in these patches 
>>> from the community.
>>
>> most distro switch from openssl to nss. is there any reason you switch
>> to polarssl in stead of nss?
>>
> 
> What do you base the "most distro" assessment on?
> 
> Are you aware of any website discussing the advantages of the "big" SSL
> providers (OpenSSL, Mozilla NSS, GnuTLS, PolarSSL, CyaSSL, ...)?

http://fedoraproject.org/wiki/FedoraCryptoConsolidation
http://rcritten.fedorapeople.org/nss_compat_ossl.html
http://www.mail-archive.com/help-gnutls@gnu.org/msg00676.html
http://fedoraproject.org/wiki/Nss_compat_ossl
http://lists.alioth.debian.org/pipermail/nut-upsdev/2010-December/005090.html

-- 
  Levente   "Si vis pacem para bellum!"

Re: [Openvpn-devel] Documentation and alternative SSL backend patches

[Farkas Levente]

On 12/02/2010 10:05 AM, Adriaan de Jong wrote:
> Hi List, 
> 
> We've been working on OpenVPN in preparation for a security evaluation. This 
> entailed documenting OpenVPN at a relatively high level, removing the 
> dependencies on OpenSSL, and adding support for a simpler, easier to evaluate 
> library (PolarSSL).
> 
> This was done in a series of patches:
> - Patch 1: Adds documentation to OpenVPN through Doxygen.
> - Patch 2: Splits out OpenSSL-specific code, defining a clean "backend" 
> interface for both the crypto and SSL modules. Splits the SSL module into 
> channel setup and verification sub-modules.
> - Patch 3: Adds a backend for PolarSSL.
> 
> We'd love to release these patches to the community. Unfortunately, the 
> patches are now based on 2.1.4, and need to be rebased to a newer version. 
> Before we spend time on updating the patches to the current revision of 
> OpenVPN, we'd like to know whether there is an interest in these patches from 
> the community.

most distro switch from openssl to nss. is there any reason you switch
to polarssl in stead of nss?

-- 
  Levente   "Si vis pacem para bellum!"

[Openvpn-devel] server log not very useful

[Farkas Levente]

hi,
if i set in my server's config:
tls-server
and on the client's conf:
remote-cert-tls server
ns-cert-type server
then if i generate a new cert for the server and forget to set it to 
server, then it's very hard to find out the problem. ie. neither from 
the server nor the client's log file contains any info about the 
problem's reason. it's be useful if there be some kind of info about the 
real reason other then:

TLS Error: Unroutable control packet received
[ECONNREFUSED]: Connection refused
thanks.
regards.

--
  Levente   "Si vis pacem para bellum!"

Re: [Openvpn-devel] [PATCH] openvpn over ipv6 support -v0.4.6

[Farkas Levente]

any change to megre it into upstream openvpn?

On 09/26/2009 04:05 PM, Bernhard Schmidt wrote:

JuanJo Ciarlante  wrote:

Hello JuanJo,


I'm(back) working on openvpn/ipv6 endpoint support, aka udp6/tcp6,
please refer to README.ipv6[1] and TODO.ipv6[2] for more details.

All snapshots are unittested for correct {udp,tcp}v{4,6} operation
under GNU/Linux and win32 (the latter x-compiled under the former ;).


Thank you very much, your work is highly appreciated!

I've updated my Ubuntu PPA repository of IPv6-enabled OpenVPN with your
patch. It contains the Ubuntu Karmic 2.1~rc19-1ubuntu2 package patched
for IPv6 transport, compiled for Karmic and Intrepid. The Intrepid
version should work fine on Debian Lenny as well.

You can find those packages on
https://launchpad.net/~berni/+archive/ipv6/+packages . I have not
observed any problems in my easy usecase (static Point-to-point tunnel
over UDPv6), but no guarantees for anything.



--
  Levente   "Si vis pacem para bellum!"

Re: [Openvpn-devel] version 2.1

[Farkas Levente]

Carsten Krüger wrote:
> Hello,
> 
>> wouldn't be it better to release the current version as 2.1 and all
>> upcoming bugfix can be put into post 2.1?
> 
> +1
> But kick OpenVPN GUI from installer, it is unmaintained old crap (needs
> adminrights, didn't use management interface)
> 
> Please set a link to OpenVPN Manager
> http://sourceforge.net/projects/openvpnmngr/

imho keep the current install too (or create 2 different installer) and
can add the link.

-- 
  Levente   "Si vis pacem para bellum!"

[Openvpn-devel] version 2.1

[Farkas Levente]

hi,
it's about 3 years since openvpn-2.1 is beta and almost everyone useing
the beta version since there is no final release.
wouldn't be it better to release the current version as 2.1 and all
upcoming bugfix can be put into post 2.1?

-- 
  Levente   "Si vis pacem para bellum!"

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.0.8 and 2.1_beta15 released

[Farkas Levente]

James Yonan wrote:
> Farkas Levente wrote:
>> James Yonan wrote:
>>   
>>> 2006.09.12 -- Version 2.0.8
>>>
>>> * Windows installer updated with OpenSSL 0.9.7k DLLs to fix
>>>   RSA Signature Forgery (CVE-2006-4339).
>>>
>>> * No changes to OpenVPN source code between 2.0.7 and 2.0.8.
>>>
>>> 2006.09.12 -- Version 2.1-beta15
>>> 
>>
>> hi,
>> is there any estimate/schedule/roadmap for 2.1 final?
>> yours.
>>
>>   
> We are basically there.  Beta15 has a number of changes and fixes that
> need to be tested.  I would like to see it out in the field for 30 to 60
> days before we promote it to final.

thanks.
the reason why i waiting for the final is not because we can't use beta
(actually all of our client and server are use the latest beta), but as
the topology is only in the beta series and other product as openvpn
gui, openvpn for pocket pc etc. are all based on the latest stable or
not follow the beta series. it'd be nice to reach the 2.1 final. in this
case all other upstream packager follow this step. (eg. currently we
can't use pda (pocket pc) to connect to our server which use topology)
or we should have to rebuild the pocket pc port which is not so trivial.

-- 
  Levente   "Si vis pacem para bellum!"

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.0.8 and 2.1_beta15 released

[Farkas Levente]

James Yonan wrote:
> 2006.09.12 -- Version 2.0.8
> 
> * Windows installer updated with OpenSSL 0.9.7k DLLs to fix
>   RSA Signature Forgery (CVE-2006-4339).
> 
> * No changes to OpenVPN source code between 2.0.7 and 2.0.8.
> 
> 2006.09.12 -- Version 2.1-beta15

hi,
is there any estimate/schedule/roadmap for 2.1 final?
yours.

-- 
  Levente   "Si vis pacem para bellum!"

[Openvpn-devel] openvpn 2.1 release

[Farkas Levente]

hi,
is there any know bug in the current 2.1 beta tree? if not can we wait a
final release of 2.1 in the near future?
yours.

-- 
  Levente   "Si vis pacem para bellum!"

[Openvpn-devel] a few problem/comment/bug with version 2.1.x

[Farkas Levente]

hi,
we now try to migrate from openvpn 1.x to 2.1 topology and we's a few
problems and comments about the new versions and a few questions.
we would like to give each client a fixed ip addresses and some of them
have an own subnet behind it. the server use the
server 192.168.254.0 255.255.255.0
topology subnet
client-to-client

my questions:
- why not accept among the server.conf's push the following options:
  - persist-remote-ip
  - keepalive
  this has a good reason or just forget to include. imho it'd useful.
  "Options error: option 'persist-remote-ip' cannot be used in this context
   Options error: option 'keepalive' cannot be used in this context"

- even if i set among the server's push option
  - push "comp-lzo"
  i've got the warning:
  "WARNING: 'comp-lzo' is present in remote config but missing in local
config, remote='comp-lzo'"
  and don't see among the "OPTIONS IMPORT". is this normal or a bug?
  at the same time i've got a lots of such messages on the server:
  Bad LZO decompression header byte: 69

- neither on the server nor in the client we set any mtu. but we got
  this warning:
  WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1541',
remote='link-mtu 1542'
  is it normal, a bug, or just a warning? should i have to fix it?
  ie. define link-mtu on both end?

- if i set the above server network then i've got in the log file:
  "IFCONFIG POOL: base=192.168.254.2 size=252
   IFCONFIG POOL LIST"
  in this case i still can use in the ccd/* files eg. the following:
  ifconfig-push 192.168.254.2 255.255.255.0
  or i should have to use different network for the fixed ip? or?

- if there is a network behind the client eg. 192.168.253.0/24 then i
  have to set in the ccd/client file:
  iroute 192.168.253.0 255.255.255.0
  but if i also would like to allow client-to-client i've to set in the
  server.conf:
  route 192.168.253.0 255.255.255.0 192.168.254.2
  is it true? and in the example server.conf it's stated also a
  push "route 192.168.253.0 255.255.255.0 192.168.254.2"
  required. but in this case this route be pushed to the given clients
  itself and gives a duplicate route error when try to add.
  on the other hand the example conf files do not contains the third
  parameters, but without it the route command has no gateway! does this
  example files are wrong or i misunderstood something?
  anyway why i have to add these two lines?
  wouldn't it be much better, cleaner and easier if the client-to-client
  defined and an iroute in the ccd/* files also 'generate' the above
  route command and push command for all clients except the ones who
  owns the network?

- if i choose "topology subnet" and in the ccd/client file a:
  ifconfig-push 192.168.254.2 255.255.255.0
  then why i see on the client:
tun0  Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  inet addr:192.168.254.2  P-t-P:192.168.254.2  Mask:255.255.255.0
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100
  RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

shouldn't the P-t-P:192.168.254.1 is the right settings?


-- 
  Levente   "Si vis pacem para bellum!"

[Openvpn-devel] Re: [Openvpn-users] New subnet topology feature ready for testing

[Farkas Levente]

James Yonan wrote:

OpenVPN Addressing Topology
---
However, now I've put together a brand new topology, called "topology
subnet".  This topology is very intuitive, like the "dev tap" topology
where each client gets a single IP address from a pool, the server gets
the .1 address, clients get .2, .3, .4, etc., and all clients and the
server can communicate by virtue of possessing a single IP address taken
out of the shared VPN subnet.  Plus -- a very cool property of this
feature is that it works on Windows clients as well as any *nix system
which supports tun interfaces being configured by ifconfig with an
IP/netmask rather than the usual local and remote endpoint (Linux supports 
this, I haven't tried any of the BSDs yet).


it's amazing feature! thanks!!!


Other interesting features
--

"redirect-gateway bypass-dhcp" gets around the problem of DHCP packets 
to the local DHCP server being incorrectly routed into the tunnel.


one quick question without reading the whole docs.
i always like to know my vpn enpoint has a static ip address so if i'd 
like to access joe's vpn i can simply use joe.vpn.company.com name. is 
it possible to use this new subnet topology and somehow staticaly define 
endpoint's ip address? the best would be if i can use a central internal 
dhcp server which can give ip, subnet, dns and other address to the vpn 
clients automaticaly. is it possible with linux and windows clients?



Merging Schedule


With sufficient testing, this code will be a candidate for inclusion in 
2.1 or higher, and will be applicable to the 2.0.x branch via manual 
merging.  While this patch is not huge, it's deep enough that I don't plan 
on merging it in 2.0.x anytime soon.


i'd like to see some kind of early 2.1 or 2.1rc release since we can 
create rpm packages this and test it.


--
  Levente   "Si vis pacem para bellum!"

[Openvpn-devel] pocket pc port again

[Farkas Levente]

hi,
i search the archive and see there are a few people who'd like to run 
openvpn in his pocket pc. i just like to know is there any plan to port 
openvpn to pocket pc too? this can be one of the main usage of openvpn 
in the near future. since more and more people has some kind of pda 
(unfortunately most of them runs pocket pc), newer model has wireless 
adapter and as more free/open wireless network access become polular 
it's even become a larger user base then the laptop/road warrior users.

i read the hardest part is the tap driver port. anybody working on it?
thanks in advance.
yours.

--
  Levente   "Si vis pacem para bellum!"

[Openvpn-devel] small patch for the spec.in file

[Farkas Levente]

hi,
here is my small patch for the spec.in file in order not to overwrite 
the old config files.


--- openvpn.spec.in.lfarkas 2004-03-31 18:11:14.0 +0200
+++ openvpn.spec.in 2004-03-31 18:13:25.0 +0200
@@ -34,9 +34,9 @@
 %__install -c -m 755 %{name}.8 %{buildroot}%{_mandir}/man8
 %__install -c -d -m 755 %{buildroot}%{_sbindir}
 %__install -c -m 755 %{name} %{buildroot}%{_sbindir}
-%__install -c -d -m 755 %{buildroot}/etc/rc.d/init.d
-%__install -c -m 755 sample-scripts/%{name}.init 
%{buildroot}/etc/rc.d/init.d/%{name}

-%__install -c -d -m 755 %{buildroot}/etc/%{name}
+%__install -c -d -m 755 %{buildroot}%{_initrddir}
+%__install -c -m 755 sample-scripts/%{name}.init 
%{buildroot}%{_initrddir}/%{name}

+%__install -c -d -m 755 %{buildroot}%{_sysconfdir}/%{name}

 %__mkdir_p %{buildroot}%{_datadir}/%{name}
 %__cp -pr contrib easy-rsa sample-{config-file,key,script}s 
%{buildroot}%{_datadir}/%{name}

@@ -67,9 +67,12 @@
 %{_mandir}/man8/%{name}.8*
 %{_sbindir}/%{name}
 %{_datadir}/%{name}
-/etc
+%config(noreplace) %{_sysconfdir}

 %changelog
+* Mon Mar 31 2004 Levente Farkas  2.0_test18
+- Mark config file as config.
+
 * Sun Feb 23 2003 Matthias Andree  1.3.2.14-1.
 - Have the version number filled in by autoconf.


--
  Levente   "Si vis pacem para bellum!"

Re: [Openvpn-users] Re: [Openvpn-devel] OpenVPN 2.0 -- Project Update and Release Notes

[Farkas Levente]

James Yonan wrote:

Farkas Levente <lfar...@bppiac.hu> said:



first of all THANKS!

James Yonan wrote:


* Add an internal routing capability to the OpenVPN server to allow
client-to-client communication, without going through the tun interface on the
server.


why this is needed? ans what exactly this means?



Basically OpenVPN 2.0 is a router.  It gets packets from a single tun
interface and uses the destination address on the packet to determine which
client to route it to.  So what should the router do if a packet comes from a
client and has as its destination address another client?  Some people would
want to block this capability and other would want to allow it.  If you block
it, connecting clients can only see the central server's network.  If you
allow it, one client could browse file shares on another client.


hmm, thanks I know what's the routing, but I ask this part:
"client-to-client communication, without going through the tun.."
 ^^^


* Right now clients are allocated a single, dynamic IP address.  It would be
nice if a connecting client could specify a full subnet to be tunneled.


would be welcome!



There are several problems with this that need to be solved (which I don't
think are insurmountable):

(1) First of all, there are security implications in allowing a client to push
a route onto a server, which would be necessary if a private subnet exists
behind the client that you want to route.  Probably the server config file
would need to specify special routes for various clients, based on the client
common name.


yes, but it's possible in th 1.x (although all clients has it's own 
config file), but since I can use --ifconfig-pool (which is great) I 
don't know in advance which /30 subnet will be used by the clinet, so 
define static route is a bit problematic.



(2) In general you want to run the VPN server with reduced privilege, to limit
damage in the case that the server is somehow compromised.  But adding and
removing routes requires privilege, unless all routes for every possible
client are configured on server startup, before the privilege downgrade.


that's a good point:-(((


(3) static routes tied to specific clients interferes with failover.  Suppose
you have 2 machines running a VPN server, and for purposes of load balancing
and failover, you want clients to be able to connect to either server.  Now
once you start to have clients needing static routes, it means that the
gateway on the server's network needs to understand that a given static route
might need to point to either server A or server B, depending on which of the
two servers the client is currently connected to.  So essentially, the server
would need to be able to push routes onto the gateway.

Of course all of these problems go away if the client NATs its private subnet
onto the remote VPN endpoint.  There would also be the possibility of having
the server dynamically allocate a full netblock to the client and then have
the client do one-to-one NAT between the static addresses on the subnet and
the dynamically allocated VPN subnet.  Yet another possibility is simply to
have each machine in the remote subnet have its own private tunnel to the VPN
server.

So there's certainly a number of possible solutions, but no magic bullet that
I can think of.


I see the problems.


# The server's virtual endpoints
ifconfig 10.8.0.1 10.8.0.2


this means this server has two enpoint in the server side?



Not really.  The server's local VPN endpoint is 10.8.0.1.  This is the address
which all clients will use to reach the server.  The 10.8.0.2 is really a
pseudo-address which is not bound to anything.  You couldn't ping it for


than it'd be better to omit. it's just confusing!


example.  However you can use it as a destination for routes which exist in
the server's routing table.  When you do this, the packet will be routed to
OpenVPN which will then use an internal routing algorithm to route it to the
appropriate client.  The way to think about this in a non-confusing way is to
treat the 10.8.0.2 as the "name" of the server's tun interface, so that when
you want to route a subnet into server, you can use 10.8.0.2 as the destination.


aha, than two separete config option would be more intuitive (or it 
should have to be well documented).
in this case my first question getting cleaner. although I still thing 
that routing is better to do in the os (where it's tuned better) and 
somehow propagate openvpn's route table to the os's route tables.

do it two separate place can get confusing and may result fault.

--
  Levente   "Si vis pacem para bellum!"

[Openvpn-devel] one more request for usability

[Farkas Levente]

hi,
a few mounth ago I requested the redirect-gateway feature and James was
so kind to implement that feature. we use it but have to face another
problem. our windows 2000/xp road-warrior clinets are not so "road
warrior".  this means that the clinets has a DSL connection over which
we use openvpn's vitual interface, and they always at the same place,
but may get a new ip, but these machines always up. but unfortunately
our ISP periodicaly (after 24 hours) disconnect the connection. and here
comes the problems.
- we need to reconnect our client to the internet (redial the adsl
connection).
- after we redial restart the openvpn service.
probably you don't understand why we need to restart openvpn service?!
because we use the redirect-gateway option in openvpn! and even if we
use the ping-restart options that's not enough. since the when we redial
we can get a new ip. anyway this may happend even without redial! if the
dhcp server gives a new ip for the client than the old route table and
the old default gateway no longer valid.

what can be the solution?

a new feature for openvpn servicve:
- a new options -pre-up similar to the up script, but before the openvpn
do anything else (which can be any kind of program which run
synchronously with the same parameters as up).
- and the redirect-gateway's down and up part should have to run when
restart (eg. ping-restart) is called.

in this case we can dial in this script.

our do I misunderstood something?
thanks in advance.
yours.

--
  Levente   "Si vis pacem para bellum!"

[Openvpn-devel] one more request for usability

[Farkas Levente]

hi,
a few mounth ago I requested the redirect-gateway feature and James was 
so kind to implement that feature. we use it but have to face another 
problem. our windows 2000/xp road-warrior clinets are not so "road 
warrior".  this means that the clinets has a DSL connection over which 
we use openvpn's vitual interface, and they always at the same place, 
but may get a new ip, but these machines always up. but unfortunately 
our ISP periodicaly (after 24 hours) disconnect the connection. and here 
comes the problems.
- we need to reconnect our client to the internet (redial the adsl 
connection).

- after we redial restart the openvpn service.
probably you don't understand why we need to restart openvpn service?! 
because we use the redirect-gateway option in openvpn! and even if we 
use the ping-restart options that's not enough. since the when we redial 
we can get a new ip. anyway this may happend even without redial! if the 
dhcp server gives a new ip for the client than the old route table and 
the old default gateway no longer valid.


what can be the solution?

a new feature for openvpn servicve:
- a new options -pre-up similar to the up script, but before the openvpn 
do anything else (which can be any kind of program which run 
synchronously with the same parameters as up).
- and the redirect-gateway's down and up part should have to run when 
restart (eg. ping-restart) is called.


in this case we can dial in this script.

our do I misunderstood something?
thanks in advance.
yours.

--
  Levente   "Si vis pacem para bellum!"

Re: [Openvpn-devel] option suggestion (was Re: routing on windows)

[Farkas Levente]

James Yonan wrote:

Farkas Levente <lfar...@bnap.hu> said:



Mathias Sundman wrote:


Hi!

> we use our linux vpn gateway and some win2000 road warrior clients with
> openvpn. I would like to route all internet traffic trough our firewall
> from the windows clients.

I´ve been thinking about doing this too, but never accually tried it.

What you basicly need to do is:

1. Don´t set a default gateway on your ethernet adapter.


you have to set otherwise the vpn connection can't estabilished.



2. Add a route to your openvpn server with a /32 mask pointing to the
   gateway on your ethernet.

   In your exampel this would be done with the following command on
   Win2K where w.x.y.z is the IP of your remote openvpn server,
   and a.b.c.254 is your local gateway.

   ROUTE ADD w.x.y.z MASK 255.255.255.255 a.b.c.254

3. Setup OpenVPN as usual but also add a default gateway route to
   the TAP interface.


The reason why I havn´t tried this is because I don´t know how to solve
the problem that the ROUTE command will be diffrent for each network you
hook your laptop into. So if you don´t want to manually do this every
time, you would need to write a little app that looks at the IP and
default gateway that has been assigned by DHCP, switch to static IP and
add the correct route.

Anyone that has a better solution to this?


you see exactly the problem!
on linux I can do (eg. in the up script):
--
route add -host  dev ppp0
route del default dev ppp0
route add default dev tun0
--
and we got it, but unfotunately on windows you can't route by interface 
(or to be more precise on windos the interface is defined by it's ip 
address even if you can specify the interface).
so I'd like to suggest a new option for openvpn to be portable (like in 
the case of --route):

--route-internal
  which do exactly as the above on all platform.
since openvpn know whcih ip address has the under the tun/tap interface.
or may it would be more better if the up script has one more (6th) 
paramter and the underlying interface's ip address:

---
cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip 
underlying_ip [ init | restart ]
cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask 
underlying_ip [ init | restart ]

---
and in this case on linux we cn write an up script as:
--
route add -host $5 dev ppp0
route del default dev ppp0
route add default dev tun0
--
while on windows
--
route add $5 gw $6
route delete 0.0.0.0 mask 0.0.0.0 $5
route add 0.0.0.0 mask 0.0.0.0 $4
--
does it possible? or any better solution?



When you say "underlying_ip" I assume you mean the original default gateway
(before the up script (might have) changed it)?

I agree that it would be useful to provide an "original default gateway"
parameter to up scripts.


yes.


This would provide the support necessary to conveniently route all IP traffic
through the VPN tunnel.

Unfortunately, as is often the case with network configuration, there is no
standard API for doing this.

To make this work in OpenVPN, you would need to follow the model of tun.c and
route.c where there is a function such as get_default_gateway that has a bunch
of #ifdefs for each platform.

If you want this to work on Windows right now, I would suggest you run "route
print" in your up script and pipe the output to a program which parses out the
"default gateway" information and returns it to the script.


that's what I wouldn't like to! if openvpn already contains this code 
(get_default_gateway) and you knoe that this is very difficult to find 
out than why openvpn provide it for us?

that would be a big help!
thanks in advace:-)


Then you can do the little routing dance where you route the VPN endpoint to
the original default gateway, then reset the default gateway to point to the
TAP adapter.


that's the easier part if we already know it.

--
  Levente   "Si vis pacem para bellum!"

[Openvpn-devel] option suggestion (was Re: routing on windows)

[Farkas Levente]

Mathias Sundman wrote:

Hi!

 > we use our linux vpn gateway and some win2000 road warrior clients with
 > openvpn. I would like to route all internet traffic trough our firewall
 > from the windows clients.

 I´ve been thinking about doing this too, but never accually tried it.

 What you basicly need to do is:

 1. Don´t set a default gateway on your ethernet adapter.


you have to set otherwise the vpn connection can't estabilished.


 2. Add a route to your openvpn server with a /32 mask pointing to the
gateway on your ethernet.

In your exampel this would be done with the following command on
Win2K where w.x.y.z is the IP of your remote openvpn server,
and a.b.c.254 is your local gateway.

ROUTE ADD w.x.y.z MASK 255.255.255.255 a.b.c.254

 3. Setup OpenVPN as usual but also add a default gateway route to
the TAP interface.


 The reason why I havn´t tried this is because I don´t know how to solve
 the problem that the ROUTE command will be diffrent for each network you
 hook your laptop into. So if you don´t want to manually do this every
 time, you would need to write a little app that looks at the IP and
 default gateway that has been assigned by DHCP, switch to static IP and
 add the correct route.

 Anyone that has a better solution to this?


you see exactly the problem!
on linux I can do (eg. in the up script):
--
route add -host  dev ppp0
route del default dev ppp0
route add default dev tun0
--
and we got it, but unfotunately on windows you can't route by interface 
(or to be more precise on windos the interface is defined by it's ip 
address even if you can specify the interface).
so I'd like to suggest a new option for openvpn to be portable (like in 
the case of --route):

--route-internal
  which do exactly as the above on all platform.
since openvpn know whcih ip address has the under the tun/tap interface.
or may it would be more better if the up script has one more (6th) 
paramter and the underlying interface's ip address:

---
cmd tun_dev tun_mtu link_mtu ifconfig_local_ip ifconfig_remote_ip 
underlying_ip [ init | restart ]
cmd tap_dev tap_mtu link_mtu ifconfig_local_ip ifconfig_netmask 
underlying_ip [ init | restart ]

---
and in this case on linux we cn write an up script as:
--
route add -host $5 dev ppp0
route del default dev ppp0
route add default dev tun0
--
while on windows
--
route add $5 gw $6
route delete 0.0.0.0 mask 0.0.0.0 $5
route add 0.0.0.0 mask 0.0.0.0 $4
--
does it possible? or any better solution?

--
  Levente   "Si vis pacem para bellum!"