Re: [Openvpn-users] Re: LAN gaming over openVPN

[Erik A. <er...@te...>]

Umm, I think I'm having a problem with the reference to "real" ip's.

A VPN assigns one or both sides of the connection a different IP address for 
communicating across the VPN, attempting to use their "real" ip address 
would most likely mean trying to send packets directly to the machine, 
bypassing the VPN.  As you are using internal IP addresses, this fails 
miserably.

Note that computers can only talk directly to each other under any 
circumstances when they are on the same IP subnet.  The ip addresses you 
describe are on different subnets.

Without doing analysis of your configuration files (others could do a much 
better job there), I can say from experience:

When I ran a TAP tunnel (bridged at the server machine), I did not specify 
an ifconfig line.  All my clients got a second ip address (on the same 
subnet as my server), actually by querying my NetGear cable/dsl router that 
the server was connected to the internet through.

When I ran a TUN tunnel (not bridged), all machines (server + clients) 
received a second ip address (in a completely different subnet from any of 
them), setup through the ifconfig-pool (and related) lines in my 
configuration.

I'm guessing that LAN gaming depends on being able to discover other 
machines through broadcast requests, which is where you will have your 
problems with TUN I believe (i.e. machines are fully accessible to each 
other but the game doesn't "see" others and has no way for you to manually 
say where they are by specifying their VPN ip).


----- Original Message ----- 
From: "Oliver Wittkopf" <oli...@q1...>
To: <ope...@li...>
Sent: Wednesday, December 01, 2004 12:21 PM
Subject: [Openvpn-users] Re: LAN gaming over openVPN


> until now, im using the tap device for my openvpn network. my problem is, 
> that the clients cant ping each other with their "real" ips. in my 
> opinion, the broadcasts are responsable.
> i now read this quote:
>
>> Using ethernet bridging is only one possible solution.  If you can get 
>> your
>> client traffic to route at the IP level, then you use OpenVPN in --dev 
>> tun
>> mode to create a tun device linkage, then use route commands to route 
>> traffic
>> over the tun device.  This is somewhat more efficient than using tap 
>> devices
>> and ethernet bridging, but requires that you configure multicast routing.
>>
>> James
>
> it seams that in my case, the tun device is the better opinion. but an 
> openvpn sample config says something else, i think:
>
>
> openvpn sample-config
> # You must use 'tap'
> # if you are ethernet bridging or want to route
> # broadcasts.  'tun' is somewhat more efficient
> # but requires configuration of client software
> # to not depend on broadcasts.
>
> how could i handle, that i can ping all clients with all possible ips?
>
>
>
>
>
> Server-Config: (real ip: 192.168.1.2)
> ------------------
> port 5000
> mode server
> ifconfig 192.168.3.1 255.255.255.0
> dev tap
> client-to-client
> tls-server
> dh dh2048.pem
> ca meine-ca.crt
> key Server.key
> cert Server.crt
> ping 10
> ping-restart 120
> push "ping 10"
> push "ping-restart 60"
> verb 4
> ------------------
>
> Client-Config: (real ip: 192.168.0.2)
> ------------------
> port 5000
> remote bla.dyndns.org
> ifconfig 192.168.3.3 255.255.255.0
> dev tap
> tls-client
> ca meine-ca.crt
> key Client_02.key
> cert Client_02.crt
> pull
> ------------------
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Openvpn-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>