Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I'm connecting 2 TomatoUSB (Shibby build on WNR3500L v2) routers with an OpenVPN routed connection:

-----------------------              -----------------------
| Router 1, subnet 20 | <--tunnel--> | Router 2, subnet 21 |
-----------------------              -----------------------

Router 1 is the OpenVPN server and Router 2 is a client. Clients attached to the routers on both subnets can ping clients on the other subnet, so the tunnel and routing works.

I've enabled file sharing on both, in order to get their Samba WINS servers running. Is it possible to get name resolution across the tunnel? I've tried remote browse sync = 192.168.21.1 in /etc/smb.conf on the server side, to no avail. Also tried using the IP adress that the client gets from the OpenVPN address pool (usually 10.8.0.something), but still no joy.

share|improve this question

1 Answer 1

I think the initial disocovery of WINS servers uses IPv4 broadcast features, or it's possibly involved somehow.

Broadcast traffic is not propagated across routed (Layer 3) interfaces.

It is propagated across bridged (i.e. switched) (Layer 2) interfaces.

Fortunately, OpenVPN supports routed (tun) and bridged (tap) interfaces.

So you need to modify the "dev tun" lines in your configuration files to "dev tap" lines.

Working with virtual bridged interfaces is different than virtual routed interfaces. The virtual bridged interface on the client side must have an IP that's on the same subnet as the OpenVPN server. The OpenVPN server can assign an IP automatically but you have to make sure it doesn't conflict with anything else already on your network. In the situation I've done it, a DHCP server was running on the same box as the OpenVPN server and the OpenVPN client grabbed an IP from that. This is probably the situation with you running this on a Tomato box. Watch your configuration closely.

Also you'll need to junction the "tap0" on the server to the server network interface facing the client using brctl - and tap0 won't have an IP of its own - it'll be "bridged" or software-switched to e.g. "eth0."

It's interesting and versatile (I think multicast DNS goes over virtual bridged interfaces so Apple stuff will work across it too) - but can get messy.

It may be simpler just to run a local DNS server and use DNS to resolve the names instead.

share|improve this answer
    
In the Samba documentation, it says "Microsoft's solution was to add WINS (Windows Internet Name Service) support to Windows NT so that the computers on the network can perform a direct query of the WINS server instead of using broadcast packets", so that would imply that broadcast is not used when you have a WINS server. Also, the Samba documentation for remote browse sync states that its' purpose is to allow name resolution across different subnets, where broadcast isn't possible. –  John Reynolds Oct 3 '12 at 15:36
    
I'll be honest and I haven't really researched the finer details of this. Queries to the WINS server may work across subnets, but initial discovery of them may not. I'll look into this a bit further and update if I have time. All I know is I tried to do a very similar thing to you, but used bridged interfaces when I couldn't get it to work, and it worked flawlessly (but slowly, since it was over the Internet). –  ultrasawblade Oct 3 '12 at 19:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.