[Vpn-help] Windows Shares - second try

[Matthew Grooms]

scott wrote:
> I'm going from memory and a once-upon-a-time tangle with this same issue
> using the cisco vpn client.  It had something to with the way the WINS
> and local/master browsers behave.
> 
> As I recall, the LAN subnet you're trying to WINS browse on needs to
> reverse arp the asking node's IP.  This works flawlessly when you're on
> the local subnet.  If you sniff this with, say, wireshark you should see
> the "who's got" message.
> 
> The answer was to statically arp the vpn client's ip to the WINS
> subnet's lladdr, which is the de facto "gateway" path back to the asking
> WINS client.
> 
> It was something like ... ???
> 
> arp -Fs <your_vpn_ip> aa:bb:cc:dd:ee:ff:00 pub 
> 
> where aa:bb:cc:dd:ee:ff:00 is the lladdr (mac) of the gateway/subnet
> NIC.
> 
> Again, I'm going from a long-a-go-and-far-away recollection so the
> details may be off, but the tactic is, i think, correct.
> 

Scott,

Thanks for your input. I know where you are going with this and it is 
relevant when netbios name services is configured as a broadcast node 
type. You can determine which node type your adapter is configured for 
by looking at the ipconfig /all output. For example ...

Windows IP Configuration

         Host Name . . . . . . . . . . . . : elon
         Primary Dns Suffix  . . . . . . . :
         Node Type . . . . . . . . . . . . : Hybrid
         IP Routing Enabled. . . . . . . . : No
         WINS Proxy Enabled. . . . . . . . : No
         DNS Suffix Search List. . . . . . : shrew.net
                                             shrew.net

In this case, the Node Type is set to hybrid so the host will first try 
unicast netbios resolutions to a WINS server. If the lookup fails, it 
will fall back to broadcast mode. There are several different node types 
supported by WINS. Please see the following for more info ...

http://support.microsoft.com/kb/160177

In broadcast mode, you have the local browser elections and the winner 
becomes the master for your domain or workgroup. In this mode, broadcast 
UDP packets are used to perform name resolution and is only relevant 
when attempting to resolve a name for a host that is within the same 
broadcast domain. This should never be the case for remote access IPsec 
client when they are *properly* assigned a virtual IP address from a 
network that does not overlap with any private network behind the VPN 
gateway. Otherwise you get into a weird situation where broadcast 
requests are being forwarded via IPsec. In your scenario, by adding a 
static ARP entry to the master browser you fooled it into thinking the 
client was on the same physical network as itself. This allowed it to 
forward responses via L2 to the gateway and on to the IPsec client.

-Matthew