Re: [Openvpn-users] clients getting same DHCP from openvpn

[Josh C. <jos...@us...>]

Ove Everlid wrote:
> On 01/29/2009 01:07 PM, Jan Just Keijser wrote:
>   
>> Hi Jonathan,
>>
>> Jonathan Petersson wrote:
>>     
>>> Jan,
>>>
>>> By default tun devices establishes point-to-point tunnels not a subnet
>>> which is why you have the topology-options. As you're mentioning
>>> ifconfig-pool-perisist is a potential candidate, so is
>>> client-config-dir.
>>>
>>> Why would you rather consider tun over tap anyway? Tun is for sending
>>> IP traffic while tap allows Ethernet 802.3.
>>>
>>>       
>> tun devices will give you multiple /30 networks. With tap you can use
>> the topology option to get /31 networks.
>> I always advise people to start with a tun setup as experience has
>> taught me that they're less error-prone. Also, depending on line speed,
>> a tun setup will give you better performance then a tap setup, as there
>> is no need to pass the entire 802.3 frame headers back and forth.
>>     
Tap adapters always use subnet topology.  In the context of an Ethernet
network (ie: tap, or a physical TCP/IP LAN) a /31 is meaningless; for
practical communication you need at least 2 host addresses plus a
broadcast address to form a /30 or larger.  In point-to-point setups,
the 2 host IP's need not be part of a /31, or even contiguous; "ifconfig
192.168.0.1 172.31.0.255" is a valid, although very odd, p2p configuration.
>
> The 802.3 frame header is 14 bytes (possibly also 4 bytes FCS at the 
> end). In case a reader is not familiar with the constants. If layer2 is 
> not needed, then TUN has an edge here. If layer2 is ever needed in the 
> future, perhaps TAP shall be used from the start with client-to-client 
> disabled.
>   
The byte difference isn't the primary performance factor here (assuming
an MTU of 1500, 18 bytes is a 1.2% theoretical difference, and even less
practically because not all TCP/IP traffic is the size of the MTU.) 
Performance is impacted considerably more by the use of ARP requests to
locate hosts and broadcast traffic.  Depending on the network (size and
number/type of systems) this traffic can amount to a fair flow.

Unless there's a need to send non-IP protocols (eg: IPX) or broadcasts,
such as with Windows NBNS requests for LAN file sharing, tun is the
preferred choice.  With the introduction of subnet topology in the 2.1
branch, IP space limitations aren't an issue anymore in
Windows-supported environments (although tap still has this advantage in
prior releases.)
> Seems to me that many years ago TUN and TAP had different feature sets. 
> Today features has been added to be able to do all with either TUN or 
> TAP. Do you agree with this?
>
> E.g., such things a iroute to carve out subnets in TAP and expose them 
> to routing.
>   
You "can" route over tap interfaces, but you'll be incurring the same
performance hits as noted above.  Generally this is not something one
wants to do, but the support is there to do it through OpenVPN if the
use case exists.

-- 
Josh