But their packets will come in on VPN interfaces, so they shouldn't be a problem.
@dlakelan: Okay, I think I get it... Just a rule on the LAN zone that drops any packet from proceeding that isn't in the 10.x.x.0/24 range of the LAN, right? That will also have the useful effect of preventing other kinds of weird messages that I've seen in the OpenVPN logs, like devices trying to use the Auto-IP address, etc.to send packets through the tunnels.
Yep exactly. Probably a good rule to have in any case 
@anon50098793: Speaking of hacks, I had another one rattling around my brain and want to see if you think it's worth trying since you got somewhat deep into this mess. This assumes the lmhosts file trick doesn't work. The idea is to simply alias the remote LMBs into IPs in the same subnet as the DMB. So they would be "browsers" but not the browsers that would win election on the DMB's subnet, and presumably the DMB would want to have them "show their cards" (browse lists) to it so it would go through the browse sync mechanics. Think this has a chance, or am I all wet here?
Not clear what you mean by "alias" are you talking about taking the broadcast packets sent by the browsers in LAN1 and then somehow transporting them onto LAN2 and changing their source IP to be a LAN2 IP, and then when people talk to them... transporting them back to LAN1 etc? It makes my head hurt to think about it. You'd be much better off to just go with a bridged VPN and do filtering to keep down the unimportant traffic.
Actually, I'm sort of banking on these browser to browser contacts not being done with broadcasts, but with directed UDP, which is the default for NetBIOS over TCP/IP. The idea is simply to assign a specific unused address on the DMB's subnet to the remote LMB's IP address (using DNAT or like) so that the DMB thinks it is talking to another "browser" on its LAN when in reality those packets will get directed through the VPN to the remote LMB. But you have your finger on the weak point here -- if the DMB uses broadcast packets to survey the LAN, those won't go through the VPN. And there may be other cans of worms, too, like what happens if (when) the remote LMBs "lose" a browser election? Will they cease working? Could be...
And bridged VPN would really only be viable between two of the three locations. The third location is the business owner's home network, and there are times when they prefer that network be disconnected from the rest of the business and run its own LAN IP with local servers (e.g. DHCP). Hence the routed VPN client is best.
I really think the smcroute method is going to work well.
Just thought I'd post an update here on the activities I'd planned. I installed tcpdump on the router that is the DMB and WINS server and set it up to listen to the traffic on the VPN tunnel, with a filter to capture all of the traffic originating in the DMB's subnet and destined for my LMB outpost subnet, and vice versa. To perform this investigation, I made a VPN connection on a Windows PC outside of the network run by the router under test. I did that so I could start and stop tcpdump using OpenVPN client running under windows. My test methodology was to start tcpdump, then power on the test remote LMB and let it run for about 15 minutes. Then I would try to browse the network on a PC connected to the test network.
The Pcap files are very interesting: When the Netgear WNR3500L running DD-WRT SVN 15508M (Samba 2.x) is in place for the remote LMB, there are no errors. But when the Linksys WRT1200AC running OpenWRT 18.06.1 is in place for the remote LMB, a TCP transmission error occurs! And of course, from the user perspective, the Netgear router fills in a browse list while the Linksys does not.
What I do not know -- I just completed this after spending the weekend doing setup and learning curve activities (I had to rerun the experiment 3 times because I was filtering too much) -- is whether this error is going to be repeatable. I'll have to try it again; maybe next weekend. But if it seems to be repeatable, I think a bug report may be in order... but to whom, I wonder...
This assumes that the business owner will patiently wait for another week without network browsing, because... I did not even get around to installing smcroute and the two other packages recommended by @dlakelan yet.
@andy2244: Question: I do not see a wsdd2 or like package on the OpenWRT 18 release package lists. Is the only way to get it presently through the Samba4 package? And do you know if any of the avahi packages would be adequate for advertising the presence of two shares in a way comparable to wsdd2? I share out /var and /etc from the routers on the LAN and VPN in read-only mode most of the time and it's just a convenience for me to access the routers. The business doesn't have a need to access anything on the routers.
@Andy2244: Will you be creating a package for Samba4x-server to add into the OpenWRT 18.06.1 release -- one with the same build switches as Samba36? Based on my results this weekend, I'm not convinced that the problem I'm experiencing has anything to do with winbindd, so I'd like to try something from upstream that's later, if only just for grins (and also since anybody seeing a bug report on this will just tell me to reproduce it with Samba4 anyway). And I'd rather not have to put together a build machine just to do that, if I can avoid it. Right now, a machine I have earmarked for builds has a very old version of Ubuntu (14.04LTS -- about to go off support) on it, and I need to do the usual backup/archive/etc. before even thinking about putting a new version of the OS (and then the build system) on it.
Its here in snapshots.
Yes, samba4 is build by default with avahi support and i tested the avahi-dbus package for Linux and macOS. This will not work for Windows, so you need to run wsdd2 for windows clients and avahi for linux, maxOS, Android.
That is the plan, i need to recheck if i want to include netbios or not by default. Ideally i might try to create a samba4-server-full variant that has everything enabled.
Thats why i created https://github.com/Andy2244/openwrt-package-builder as long as you can get docker installed, than it should only take a few minutes to build packages. Samba4/wsdd2 should still build against the 18.06 sdk, so you can build compatible packages with it.
More news here folks: After researching the WSD route with respect to the Netgear WNR3500L routers, we decided against using them as backups because we didn't want the dual hassles of extroot along with the hit-or-miss proposition of finding OpenWRT binaries that would work with the build of DD-WRT we are using. (Smcroute was not included in that DD-WRT build.) So instead, we picked up some new and unopened WD MyNet N750 routers and I just finished configuring one to work as a remote VPN client and Samba local master.... and I have just found that it does network browsing properly and without the flaws that I have reported above on the Linksys WRT1200AC.
Understand here that I am using the same release -- OpenWRT 18.06.1 -- but the build is targeted for the WD MyNet N750 router. This would seem to exonerate Samba from blame, though I just checked the Samba version and it's 3.6.25-12 in the WD router whereas the buggy Linksys WRT1200AC is running version 3.6.25-10. I'll need to check out what happened in those incremental Samba builds, but I am now more suspicious of a problem rooted in the layers below Samba.
@Andy2244: Can you give me some idea of what the software stack looks like below Samba? I think some of the folks involved with maintaining those packages should see this thread.
So I don't quite understand, you were setting up to do WDS with smcroute and you put in a different kind of router in prep for that, and the samba problem went away without even doing smcroute?
@dlakelan: No, we haven't even done the WDS with smcroute yet. Maybe this weekend, after I do a few more tcpdump captures to validate the repeatability of the problem with the WRT1200AC routers.
We have on hand some old Netgear WNR3500L routers running DD-WRT that we had planned to use for backups to the WRT1200ACs (as a guard against bad acts of nature like a lightning strike that takes out the router). But those won't easily run smcroute as smcroute is not part of the DD-WRT build and DD-WRT doesn't have a supported way of installing packages -- though since it's a fork of OpenWRT, some people have occasionally had success with extracting OpenWRT binaries from packages and installing them on DD-WRT. As you can guess, one's mileage definitely varies and there's a lot of moving parts that must be aligned (libraries, toolchains, etc).
So once we decided we were going to do the WSD with smcroute method of network discovery, we needed a different backup router that could run OpenWRT with enough flash to add on the packages needed. The WD MyNet N750s fit that bill.
So today I configured the first WD router to run in the existing network as a functionally compatible replacement remote VPN client and Samba subnet LMB (but not the VPN server and DMB -- that's still a WRT1200AC) -- so Samba and NetBIOS and WINS for network discovery -- and I found that the WD router running Samba 3.6.25-12 does show the collated browse list whereas the WRT1200AC used in this capacity does not.
Now, I did the same thing last week with the Netgear WNR3500L running DD-WRT and Samba 2.0. All that showed was that the problem was in the WRT1200AC -- it didn't pinpoint where in the software stack the problem might lay. The significance of doing the same test with the WD router is that I used the same OpenWRT release and basically the same Samba server code. (Actually, exactly the same smb.conf.template as the device names in the config were the same.) So this strongly implies a problem in software operating the network in layers below Samba, and that should be of interest to anyone using the WRT1200AC with this release (18.06.1) of OpenWRT.
Weird, I wonder if there is some issue with the switch chip on the WRT device?
You may be right. Take a look at screen grab of the Wireshark display below. The TCP error occurs on a packet being sent from the DMB (10.192.158.1) via the VPN tunnel to the one and only client computer (10.192.188.41, a laptop running Windows 10) on the LAN side of the "remote LMB under test". It transits through the locally-connected router, which was the WRT1200AC in the case of this erroneous packet, which was captured by a tcpdump instance running on the DMB and instrumented to capture tunnel traffic between the two subnets. So Samba on the "router under test" is not even involved. I should have noticed that earlier. Your post hinted to me to take a second look at it. What is truly weird is how this sequence of packets results in tcpdump detecting an error at the DMB. The remote "LMB under test" must be involved because it is the only variable involved here -- the DMB is 350 miles away from me and I can't touch it (though I do have remote access to it)!
BTW, if anybody is dangerous at editing these posts, I could use a hint about how to stretch the image to fit the width of the available post area... Found the spot in the composer to change the image size and I made it a bit bigger... and then the system shrunk it back... sorry, folks... I'm putting the original back to get rid of the distortion...
I wonder if you ever got something working here particularly with the smcroute method?
Not yet. The business owner that handles the IT-related stuff needed to be away for a couple of weeks on unrelated business. He's back now and I think we're set to try this coming up this weekend. I do want him to be around when we make this move since if we want to unwind it for any reason, he'll be right there and can restore config backups created before any changes are made. I'm now convinced that the Samba36 server package is probably broken for doing cross-subnet network discovery and browsing. Perhaps Andy's kitchen sink version of Samba4 will do the trick, but we're going to move on since most of the computers in this network run Windows 10.
Here's a question I'll throw out for the community's consideration: Right now I'm configuring a dnsmasq option to set the node type on each computer to h-node (option 46,8). Anybody have a suggestion (with successful implementation, preferably) for which of the other 3 node types to choose when moving to WSD?
Looks like I can answer this one myself. This article from awhile back has info on it. It looks like if you're not setting up a WINS server, then you just omit the DHCP option completely and the node should configure itself as a b-node.... though on an individual basis, a computer here and there might be configured differently with user intervention.
Good luck with testing smcroute. It seems perfect for this purpose.
@dlakelan: Problem with smcroute in OpenWRT 18.06.1: According to the logs on my router, I'm running version 2.0.0 (the System...Software view in OpenWRT reports version 2.0.0-2), while the 'phyint' option was not made available (according to the GIT changelog) until version 2.1.0. The log reports that 'phyint' is not a valid command, and since I'm running v 2.0.0 and that was added in v 2.1.0, it's not surprising that it is complaining to the log. I don't wish to broadcast on all interfaces (including to the WAN), so I will not be pursuing this further until I can get a build of a more recent version of smcroute.
Edit: The installation of iptables-mod-ipopt caused (dependency) the installation of kmod-ipt-ipopt as well, and I was able to add the iptables rule to modify the TTL with no problem... it's visible in the firewall status. Just need a recent build of smcroute now...
