= Windows Browsing and Shares =

[[TOC(depth=3)]]

On a local network, Windows uses network broadcasts to "discover" other Windows-centric services, such as shared folders, printers, etc.

To make browsing and shares work over a routed VPN, additional setup is required since there is a routing barrier between the virtual VPN network and the remote LAN.

== Overview of Solution Options ==

There are a few ways to solve this problem. The sections 

1. Set up local DNS for the remote LAN and push it to VPN clients
2. Put the LAN systems into public DNS (can still serve RFC1918 addresses this way)
3. Set up a WINS server (either Samba or Microsoft's server solutions)
4. Hardcode IPs into a hostsfile or similar
5. Use IPs instead of hostnames to reach resources
6. Use tap instead of tun (though this has other drawbacks: see below)

=== Using local DNS ===

Many "home routers" (SOHO type equipment) keep track of connecting PCs and can define a local domain. Using ".lan" for the domain is sometimes popular, or you can make one up. If you own your own domain, you can also use a subdomain of yours, like "internal.example.net." If your router doesn't do this, you can look at solutions like dnsmasq or ISC's dhcpd/named if you want to run your own DHCP+DNS.

So long as your router is able to both track DHCP+DNS and respond to VPN clients, you can use the `--push "dhcp-option"` to push both DNS and DOMAIN options. Windows clients automatically apply these to the adapter (non-Windows clients need script support -- see the manpage for this option for details.)

=== Using public DNS ===

If you have your own domain, you can simply put your LAN systems into public DNS (optionally done automatically by way of dynamic DNS if you'd like.) This has the advantage that you don't need to push any DNS options: simply use the DNS name you've chosen.

For example, if you own the domain "example.net", a subdomain for your LAN could be called "internal.example.net", and you'd reach "pc1" by using "pc1.internal.example.net". This method does work for RFC1918 IPs on your LAN, although be aware some resolvers (like dnsmasq) are sometimes configured to drop external RFC1918 replies.

=== Using WINS ===

Another option is using a WINS server, either hosted by Samba, or by the Microsoft server methods. A client that is able to understand the "WINS" option pushed with `--push "dhcp-option WINS ..."` can use this method. It's often more convenient to set up DNS.

=== Using tap ===

Yet another option is to use tap instead of tun. You give up some transport efficiency and lose some security protection OpenVPN provides in tun mode; however, tap is an extension of the Ethernet layer instead of the IP layer that tun works at. This means the broadcasts Windows file sharing uses can be transported across the VPN, and specifically NBNS and related service discovery.

It's best not to use this solution unless none of the above solutions are acceptable due to the overhead of both the transport and increased broadcast traffic.