Re: [Openvpn-users] Beta11 - client-to-client

[Leonard Isham <leonard.isham@xxxxxxxxx>]

On Tue, 2 Nov 2004 09:55:09 -0500, Adam Pavelec
<apavelec@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Tuesday, November 02, 2004 2:12 AM [GMT-5=EST], Mathias Sundman
> 
> 
> <mathias@xxxxxxxxxx> wrote:
> 
> >> I've been experiencing a problem regarding the client-to-client
> >> directive in my bridged configuration.  It seems that when I have
> >> two or more remote clients behind the same subnet requesting
> >> resources from eachother by netbios name, their traffic is routed
> >> through the OpenVPN tunnel instead of being routed locally.  I've
> >> been running Beta11 since its release, and it seems that this issue
> >> has just recently appeared.  Am I missing something in my server
> >> configuration to prevent this from happening?
> 
> > I guess it "works as designed". As you have created a bridge you now
> > have two "local subnets" connecting these two hosts, just like if you
> > have had two physical network adapters in each machine and had
> > connected them both between these machines.
> >
> > It's a matter of name resolution. Unfortunally I don't know how you
> > should be able to set a "prefered" subnet. Windows will probably
> > broadcast both subnets, or use the IP address it receives from a WINS
> > server if you have specified one.
> 
> Not sure if this is even possible, but maybe there could be a directive
> that's pushed to the client that can take care of this programmatically.
> 
> > I can only think of two ugly work arounds. Add the local hosts you
> > want to communicate with locally to your LMHOSTS file or add statical
> > entries in the WINS server.
> >
> > You could also try the changing the network adapter binding order to
> > see if that have any effect.
> >
> > Maybe the metric value for the "local subnet" route can have some
> > effect too.
> 
> I fully understand the whole theory behind this, but it's really strange
> that it only recently started affecting me.  It all began few weeks ago when
> I noticed my VNC connections from my Wi-Fi connected laptop into my wired
> desktop becoming completely laggy.  Pings were sometimes 4,000+ms, and I
> began to think it was the Wi-Fi connection at my new residence.  Then I
> actually paid attention and noticed that the pings were resolving to the
> desktop's OpenVPN 'virtual' IP address instead of its local IP address.
> 
> And on Tuesday, November 02, 2004 7:50 AM [GMT-5=EST], Leonard Isham
> <leonard.isham@xxxxxxxxx> wrote:
> 
> > OK without seeing your exact configuration here is what I believe is
> > happening, and I do have to say it does work as designed as this is
> > Microsoft's architecture controlling the behavior.
> 
> http://pavelec.net/adam/openvpn/configs/
> 
> > Assumptions:
> > 1. The server site is the location of netbios resolution because one
> > of the following:
> > - You are using WINS  at the server site
> > - the remote site is always the master browser for theses systems
> > because of specific configuration or the fact that servers and domain
> > controllers are heavily favored.
> 
> The latter would be my case -- we have no WINS server at the server site...
> 
> > 2. The remote computers do not have any "infrastructure servers"
> 
> Not sure what this means, but it's probably the case.  There are no Domain
> Controllers at the server site -- it's simply a peer-to-peer network in the
> classical sense.
> 
> > What happens:
> > 1. Netbios resolution looks to the WINS server or master browser which
> > has the bridged IP address related to the netbios name.
> 
> So, the OpenVPN client is receiving name resolution from the Master Browser
> at the server site?
> 
> 
> 
> > Possible resolutions:
> > 1. Add static entries into WINS with the local IP addresses for the
> > remote systems.
> > 2. Change name resolution order to LMHOSTS first and maintain the file
> > on the machines.
> > 3. Change to routing instead of tunneling.  (more complex from the
> > network side, but properly configured would resolve your netbios
> > issues)
> 
> I may just end up removing the client-to-client form the server config.
> It's a wonderful idea, but it seems that there's just too much room for
> no-so-optimized routing in a bridged configuration.
> 
> -Adam

Adam,

The issue is with MIcrosoft's name resolution.  Both clients are,
apparently using the master browser on the server LAN and it only
knows the TAP IP address.  Therefore using netbios will cause you to
use OpenVPN.

Removing client-to-client will not make resolve the issue, but might
make it worse.

Moving to a tunnel *and* implementing WINS should resolve this issue.

>From the OpenVPN Man page on the web:

"Because the OpenVPN server mode handles multiple clients through a
single tun or tap interface, it is effectively a router. The
--client-to-client flag tells OpenVPN to internally route
client-to-client traffic rather than pushing all client-originating
traffic to the TUN/TAP interface.

When this option is used, each client will "see" the other clients
which are currently connected. Otherwise, each client will only see
the server. Don't use this option if you want to firewall tunnel
traffic using custom, per-client rules."


-- 
Leonard Isham, CISSP
Ostendo non ostento.

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users