Re: [Openvpn-users] Warcraft 3 over a TAP bridge - people can't see each others hosted games

[David S. <ope...@to...>]

Jan Just Keijser wrote:
> David Sommerseth wrote:
>> Bonno Bloksma wrote:
>>  
>>> Hello David,
>>>  
>>> A computer connected via a tap device is like it is connected via a 
>>> switch. So no routing is involved.
>>> Anything pertaining to routing does not apply and although every 
>>> option that has something to do with routing could have an extra line 
>>> in the man pages telling it does not apply with tap devices.... it 
>>> does get a bit overdone that way.
>>>  
>>> A computer connected via a tun device is like it is connected via a 
>>> router. Therefore both sides need to know about routing.
>>>     
>>
>> Yes, I know the fundamental differences between tun and tap.  I just 
>> thought it provided routing information back to the server as well 
>> about the client network, not regarding to if it was tun or tap.  But 
>> when double checking against the source code (multi.c:1100) I see 
>> iroutes are only added on tun devices.  Sorry about that confusion.
>>
>> One thing I then do not completely understand ... Let's do some ascii 
>> art:
>>
>>     <Client LAN - 192.168.50.0/24>===<openvpn client - TAP:10.8.0.5>
>>                                             //\\
>>                                            //**\\
>>                                           INTERNET
>>                                            \\**//
>>                                             \\//
>>       <Server LAN - 172.16.0.0/24>===<openvpn server - TAP:10.8.0.1>
>>
>> The server will be able to route client LAN IPs into server LAN and 
>> responses will be routed directly back again, as long as the client 
>> have --route 172.18.0.0 255.255.255.0 10.8.0.1.
>>
>> But if you also want the server LAN to access the client LAN, you must 
>> then   have an explicit route on the server saying:
>>
>>       route add -net 192.168.50.0 netmask 255.255.255.0 gw 10.8.0.5
>>
>> Without this route, the traffic to client LAN will never cross the 
>> tunnel.   And I thought this was the issue the --iroute solved.  Well, 
>> it solves it in tun mode, but obviously not in tap mode.  There is no 
>> other way that the server can know about the network behind the client 
>> LAN.
>>   
> so far you've understood it completely. However, the question becomes: 
> why do you need a 'tap' network in this case? This looks like a routed 
> network setup, for which 'tun' is much better suited.

Indeed.  It was more a theoretical and mental exercise.  I'm just wondering 
if this would help on broadcast packets somehow?  How would actually 
broadcasts to 255.255.255.255 be handled?  And what about multicast?

>> Or am I missing something here?  You will always need that explicit 
>> rule on the server whenever using TAP, right?  In TUN mode, this would 
>> be solved by   a --iroute 192.168.50.0 255.255.255.0, right?
>>   
> some general rules about when to use 'tun' and when to use 'tap':
> 
> use 'tun' when
> - all you're using is TCP/IP traffic
> - you want a routed setup
> - there is no need for the clients to be in the same IP range as the 
> server (though I'd love to see some proxyarp tricks for this)
> 
> use 'tap' when
> - you want to use non-TCP/IP traffic (netbios, IPX, etc)
> - you need to pass full ethernet frames over the VPN
> 
> use 'tap' in bridging mode when
> - you want to make the clients appear as if they're on the LAN
> - you want to assign (DHCP) addresses yourself, e.g. using a local DHCP 
> server
> - you need LAN broadcast traffic to be sent over the VPN
> 
> In 'tap' mode, however, you have to take care of (TCP/IP) routing 
> yourself. Because you're passing full ethernet frames it becomes hard to 
> define routing: there's no such thing as "generic" routing in Ethernet. 
> What if you can do TCP/IP routing in 'tap' mode but not IPX routing?

Yupp! Completely agree!

>> Using bridging on the server will not change much at all.  Binding the 
>> local LAN interface and the TAP device, the TAP device will not have 
>> an explicit IP address on the server (because the bridge interface 
>> have the IP address), and the IP address the client will receive, must 
>> be in the range of the server LAN.  Still in this scenario, you would 
>> need that explicit route on the server.  As the client LAN is still an 
>> unknown network for the server LAN, the traffic would be routed via 
>> default gateway instead.
>>
>> Doing bridging on the client network would only work if it is a box 
>> with 2 interfaces acting as the default gateway - and then the clients 
>> LAN would have the same network range as the server LAN.  The client 
>> OpenVPN would then act as a pure bridge between the networks.  It 
>> could even be without any IP address on it's local network interface, 
>> right?  If the same network interface sending the encrypted VPN 
>> traffic is bridged with a TAP device, the traffic would go in a circle 
>> and not end up any where - so that would not be a possible solution at 
>> all.
>>
>> I just have a feeling I've either misunderstood this even more, or 
>> that OpenVPN is "missing" a feature in TAP mode, in regards to client 
>> routing, as the client side network cannot be routed based on info 
>> from the client - it must be set on the server.  (Yes, I do see the 
>> danger if two clients connects with the same local client LAN IP range)
>>
>>   
> this is a very interesting remark/question ... I am not entirely 
> convinced that something is missing but I also do not know how to deal 
> with such a setup:
> normally bridging applies *only* to the server; if the client is bridged 
> then who assigns the IP address? does it get its IP from the server or 
> from the LAN?

That's a good question.  Actually, after have been thinking about this. 
client-only-bridging will be messy, at least in a TCP/IP perspective.  As 
you say, who will assign IP addresses?

 > On the other hand, how can one see the client LAN from the server in
 > 'tap' mode?  to be honest, I don't know...

In a setup where both client and server does bridging against internal 
network interfaces on both sides, in theory, the TAP devices could be 
without IP addresses.  In such a setup, the OpenVPN tunnel would only act 
as a cable between those two networks, to say it very simple, since all 
ethernet frames are transported over the tunnel.  But of course, this is 
not a solution for a redundant setup, as the client side requires a 100% 
available link to the server side.

Anyway, thanks for your time thinking about this as well - good to know I 
wasn't far away from reality based what you could confirm now :)  As I said 
earlier, this was primarily a theoretical exercise, to see how to use and 
not use OpenVPN :)


kind regards,

David Sommerseth