|
|
Dick, Certainly bridging is less efficient, though it's a straightforward configuration for the Windows <-> Linux case and gets the Win32 SMB protcol talking over the tunnel (which by default depends on broadcasts) which in turn gets file sharing and network neighborhood browsing working on the Windows side. You can certainly do all this with routing as opposed to bridging, but then you need to set up a WINS server or some other mechanism to allow inter-subnet windows browsing to work. But as you point out, bridging doesn't scale well over lower bandwidth links. It would be nice to have some kind of HOWTO that explains how to set up a windows client to use routing (not bridging), and to have full windows network share browsing functionality to other windows or samba servers, and not to depend on broadcasts for SMB name resolution. James "Dick St.Peters" <stpeters@xxxxxxxxxxxxx> said: > James Yonan writes: > > Since you want the incoming tunnel to appear to be on the private subnet, you > > need to bridge. > > James, > > This is correct only if you want broadcast to work. Otherwise simply > using normal routing will do just fine and is the way to go. > > If you don't absolutely need broadcast, you want it not to work! A > broadcast level that's 1% background noise on a 100 Mbps LAN is 1 MBps > and will completely swamp a 1 Mbps tunnel. > > Bridging on WAN links has always been rare, for good reason. You want > a router between a WAN link (or tunnel) and a LAN to limit the traffic > that gets on the WAN link. > > As I write this I have 7 users tunneled into our tunnel server, and 6 > of those 7 are joined to the server's subnet. None of these tunnels > are bridged. > > -- > Dick St.Peters, stpeters@xxxxxxxxxxxxx > -- |