Louis
>
>  > This effectively pushes EVERYTHING down the tunnel (DNS, DHCP,
>
> This is my goal, I want is everything over that wireless link to/from
> m0n0 to be completely encrypted, I don't want to see DNS traffic passing
> through wirelessly.  In fact, wouldn't any VPN solution want this to
> happen?  People could sniff and all your DNS traffic and then gain
> insight as to where you are going which would seem to partially defeat
> the idea of VPN.  How does IPSec and PPTP do it?
>

Weeelll - it depends.

There are basically two factors at work here:
	- Voluntary vs compulsory tunnels
	- Split vs non-split routing

In our case (OpenVPN) we only have voluntary tunnels, so we can ignore this.

Split routing is where the client (user) is able to send some data via the VPN 
and some via the the direct (real) connection.  For a road warrior scenario 
this is a common consideration.  There are a number of issues:

1.  If the user can send and receive directly and via the VPN at the same time 
(split routing)  then it is possible, for example, for a worm (such as SQL 
slammer) to infect the users system from the direct link and then jump down 
the VPN.  (It is ESSENTIAL to use a personal firewall system in conjunction 
with the VPN client to handle this issue).

2.  Non-split routing forces all the users traffic down the VPN - this causes 
performance and possibly reachability issues.  It also means that all 
internet traffic exits via the corporate firewall solution (a plus point for 
security but potentially bad for performance/utilisation reasons).

3.  A user operating at a remote Intranet site will not have access to local 
services at that site whilst using non-split routing because all traffic to 
local resources will be via the Internet, and probably filtered by the local 
firewall.

Another factor is the type of VPN.  We tend to use 'VPN' as a throw-away term 
to describe two rather different systems: remote-access VPN and site-to-site 
VPN.  In the latter case, we certainly do want all traffic between sites to 
be protected by the VPN.  In the former case this is not always the automatic 
best choice.

> This brings up another question, since I don't have another physical
> laptop/wifi station at the moment I have tested by putting another wifi
> interface in my Thinkpad.  Now when I sniff my channel from that second
> interface *I do* see some cleartext traffic going by.  Now I imagine
> this is not being picked up from the air, but from the local machine
> depending on how the stack or routes are configured?  Not a valid test I
> know but any input on this would be nice.  (I saw this when testing PPTP
> from Linux as well).
>

I actually do some of my testing using a similar setup.  In general, if I run 
ethereal on the wireless interface I see all traffic to UDP/5000 encrypted.  
If I look at the actual tun/tap interface then I see the traffic in plain.

If I set the redirect-gateway + local option then all I see on the wireless 
interface is encrypted , except for DHCP admin stuff.

If I set rediect-gateway only then stuff addressed to the local net is in 
plain, everything else thruough the tunnel.

What kind of stuff can you see in plain the wireless interface?

Good idea to check your routing table setup once the tunnel is up to make sure 
it is sane.  For Windows XP I would expect to see a difference in the routing 
table between the two redirect modes.

>  >specify the redirect-gateway + local push option which is correct for
>  > situation where clients are on the same network as the server.
>
> I have this working according to the openvpn client messages on in
> Windows XP, but I get an error for the redirect-gateway + local push
> option using the openvpn client on Linux (FC3).  [will paste]
>

That may be a known issue - I think I saw something about this on the OpenVPN 
list a few weeks ago.

> I will add a section to the doc as to how to configure the client in
> Linux.  Also will try to segment it better to show a local VPN
> configuration vs a remote VPN configuration.
>

Yes - they are really different scenarios.

>  >OpenVPN now has an official port number  assigned by IANA (1194).
>
> Will the GUI screen mention to add firewall rules or offer to add them
> automatically when you turn it on?  T
>

I must confess that I am still thinking about this.  You may recall in my docs 
that I make the point about handling dynamic addresses for the WAN interface.  
I still think the best thing to do is listen on all, and use filters to only 
include the ones you actually want.  I will mess about with this some more - 
maybe just auto-set the rules if a single interface is selected?

>  > You might want to try the local wireless network scenario using TAP
>
> I will check this out, I did see that you suggest this in your
> documentation which I based a lot of what I did off of.  TUN seemed to
> work more clean, and I was also big on setting the configuration to
> something that can be supported by the most clients, since I plan on
> having Windows, Mac, and Linux clients using OpenVPN when its all done.
>

In general, the network protocol engineer in me cringes at the idea of Layer 2 
tunneling (in this case ethernet over IP, but I hate PPTP and L2TP as well).  
However, PPTP and L2TP exist because of the user auth + address assignment 
issue.  In the case of TAP-style tunnels it really comes down to bridging and 
using features like captive portal (which is driven by MAC addresses).  I 
have an environment where all my users connect via wireless to the m0n0 and 
then controlled by the captive portal - hence I use TAP because it all just 
works.

>  > Alse I reccommend TinyCA (http://tinyca.sm-zone.net/) for managing
>
> Will there be any GUI tools added to the m0n0 OpenVPN screens to
> generate all the certs?
>

I have not yet discussed this with Manuel.  I would like to see this feature - 
particularly as I am currently working on per-client configs that over-ride 
the one-size fits-all stuff we have at the moment.  As this is completely 
driven by unique client certs it makes a lot of sense to make m0n0 a CA.  The 
big drawback is the (current) need to have the openssl binary on m0n0 - this 
is a big fat thing that will need a bigger image - and we are already getting 
close to the limits for some smaller systems.

There is a PHP openssl function library, but it only implements a subset of 
the openssl API.  I am investigating the possibility of extending this to 
handle the CA requirements with a much smaller footprint. 

Regards
Peter


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.