[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

[Openvpn-users] Re: OpenVPn 2.0 Debian and Roadwarrior/IP-DHCP...


  • Subject: [Openvpn-users] Re: OpenVPn 2.0 Debian and Roadwarrior/IP-DHCP...
  • From: Charles Duffy <cduffy@xxxxxxxxxxx>
  • Date: Mon, 10 Jan 2005 08:46:35 -0600

Lars Schimmer wrote:
I have to setup a VPN for my work here.
Features are roadwarriors connect to a server from all over the net with Windows
and Linux.And the Roadwarrior should get a IP from our pool here.
So far I watched over OpenVPN website and found only bridging subnets.
But I only want 5 IPs to aquier for OpenVPN and for a user it should look like this:
1. Connect to the VPN server
2. Obtain a IP from our pool
3. be online as if he works local in our pool

There are two basic kinds of configurations:

- Bridged configurations, aka tap mode. These use an IP from your preexisting pool; in effect, the VPN just provides a long ethernet cable from your office to the VPNned clients.

- Routed configurations, aka tun mode. These put VPNned systems on their own subnet, such that routes need to be defined to get between there and your regular network.

When you ask for IPs to come out of your preexisting pool, you're implying that you want a bridged configuration. However, that may not actually be The Right Thing.

Using tap mode allows you non-IP and broadcast traffic. That's not necessarily a feature, though -- if every packet of internal broadcast traffic on your network means N packets of external traffic (where N is the number of connected VPN clients), the bandwidth cost can add up fast. (Additionally, the ethernet frame headers are transmitted, so there's extra overhead with every packet).

Using tun mode, on the other hand, you set up a new subnet hanging off the VPN server; this subnet supports IP traffic only. If your VPN server and your default gateway aren't one and the same, you'll want to have the gateway route VPN-destined packets (which it can distinguish because they're on a distinct subnet) over to the VPN server -- but once that's configured, there's nothing more to it.


I strongly recommend using tun mode unless you have a strong requirement for non-IP protocols or are completely unable to modify the routing rules at your office. Setting up a subnet for the VPN is no harder than putting "server 172.16.0.0 255.240.0.0" and adding a rule on your gateway telling it to forward packets destined to 172.16.0.0/12 over to the VPN server, and the advantages are well worth it. [172.16.0.0/12 is just used as an example here, and you probably wouldn't want to use that whole range unless your VPN is going to be absolutely huge -- it's referenced to be exemplary as a section of reserved space that most networks don't use for anything].




-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users