Samba cross-subnet browse list collation not working

It lists nothing on the "Remote router" as an output, either... BTW, I did a search of the OpenVPN24 man page and found nothing pertaining to multicast configuration. Allegedly it works even for tun interfaces, but I've only seen people succeed with it using tap...

Yep. It's a sticking point. Not sure where to go now. Will require some thinking... Tap is a possibility. How many sites are there participating?

Tap is not something we really want to do if we can avoid it. There are 3 sites with subnets behind them and we have to allow for VPN connections over the internet from phones and laptops running OpenVPN-compatible client software.

Is there any reason to believe that a more recent build of smcroute might fix this?

Now this is weird: The stuff I noted above about /proc was read from the 'Remote router' -- the one sitting right here next to me. However, on the VPN Server router, the output of cat mc_forwarding is 1 for both the tun0 and br-lan interfaces. The smcroute.conf is exactly the same for both routers.

Why would an OpenVPN Server instance permit multicasting while an OpenVPN client instance denies it? Hmmm... the server does push the (non-multicast) routes to the clients.

Do you have any firewall restrictions that would prevent the multicast traffic?

My basic thought is to create a separate tap based VPN network specifically to transport just the browse info and any other multicast traffic that might be useful (MDNS, printer discovery etc)... Leave your other tun based VPN in place for "real" traffic.

Take a look at this thread

Seems it should work over TUN, make sure you have the TTL of the multicast packets being modified on both ends.

I don't think so. I have the traffic flowing freely through the tunnels with only one exception: I block DHCP traffic from entering the tunnel using this custom rule:

iptables -A INPUT -i tun0 -p udp -m multiport --dport 67,68 -j REJECT

This should affect only UDP packets destined for ports 67 and 68 and let everything else through. The UCI firewall config for inter-zone forwarding looks like this:

config forwarding
	option dest 'lan'
	option src 'vpn'

config forwarding
	option dest 'vpn'
	option src 'lan'

config forwarding
	option dest 'wan'
	option src 'lan'

Here the 'lan' zone corresponds to interface br-lan, and the 'vpn' zone corresponds to interface
tun0. I do have one firewall traffic rule that DROPs these multicast packets if (when) they reach the wan zone, but that's all.

It's past my nap time and my mind is mush. Will take a look at that thread in the AM and reply further then.

1 Like

I think the next thing to do is make sure you are setting TTL and try tcpdump on tun at both ends to see if the traffic is being sent or what. You might need to set TTL to 3 or even 4 to make the appropriate hops.

Well, to quote both Dinah Washington and Esther Phillips, "What a diff'rence a day makes!" Or in this specific case, a power cycling -- because I powered off the "remote router" that sits on the table next to me here last night, and this morning it is behaving quite differently: mc_forwarding is set to 1 and the results of "ip mroute show" are as follows:

root@redacted:~# ip mroute show
(10.192.188.41, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.158.20, 239.255.255.250) Iif: tun0       Oifs: br-lan  State: resolved
(10.192.158.140, 239.255.255.250) Iif: tun0       Oifs: br-lan  State: resolved
(10.192.158.108, 239.255.255.250) Iif: tun0       Oifs: br-lan  State: resolved
(10.192.158.165, 239.255.255.250) Iif: tun0       Oifs: br-lan  State: resolved
(10.192.158.137, 239.255.255.250) Iif: tun0       Oifs: br-lan  State: resolved
(10.192.158.133, 239.255.255.250) Iif: tun0       Oifs: br-lan  State: resolved
(10.192.158.123, 239.255.255.250) Iif: tun0       Oifs: br-lan  State: resolved
(10.192.158.215, 239.255.255.250) Iif: tun0       Oifs: br-lan  State: resolved
(10.192.158.201, 239.255.255.250) Iif: tun0       Oifs: br-lan  State: resolved
(10.192.158.106, 239.255.255.250) Iif: tun0       Oifs: br-lan  State: resolved

At the same time, the VPN server router's response is:

root@redacted:~# ip mroute show
(10.192.158.106, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.158.108, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.158.215, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.158.20, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.158.165, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.158.201, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.158.137, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.158.133, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.158.123, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.158.140, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.158.114, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.158.237, 239.255.255.250) Iif: br-lan     Oifs: tun0  State: resolved
(10.192.188.41, 239.255.255.250) Iif: tun0       Oifs: br-lan  State: resolved

So it appears that the tunnels are no longer impediments to multicast traffic.
But we're still not seeing the opposite subnet's computers and connected devices
in the W10 Network view, so the next move will be to give tcpdump a spin and
see what it unearths.

1 Like

Tcpdump on the remote br-lan and then on the remote tun0 and see what happens, the most likely idea is that TTL isn't right. Make sure you have the TTL ipopts packages installed on both ends. I think you want to set TTL to 3, so that the hop into the tunnel and the hop onto the remote lan leave you with TTL 1

Edit the fact that one side has all these sources coming in br-lan and the other side has them coming in tun0 suggests that the kernel is seeing the packets. But it might not be sending them out the receiving side bridge if the TTL is too small.

Before doing anything, I bumped up the TTL to 5 in the firewall MANGLE table rule on both routers. After restarting the firewalls, the 'ip mroute show' output on both continued to show computers on both sides of the tunnel. On the remote router (VPN client sitting here with me), I ran the following tcpdump command:

tcpdump -i tun0 -n -s 0 -vv dst 239.255.255.250 -w /var/log/tun0-WSD.pcap

I attempted "Network" views on the laptop here and on a computer on the other subnet (via VNC connection), and captured 61 packets, a mixture of UDP and SSDP. Each packet, however, shows a TTL of 4.

But we're not done yet here: Each computer is also running a Symantec Norton firewall, and I am highly suspicious that multicast traffic originating outside the LANs is being dropped. Investigating further....

That Norton firewall sounds likely.

Well, I tried a quick-n-dirty fix to the firewall -- I already have a custom traffic rule for it allowing traffic to flow freely among 5 subnets (the VPN overlay subnet, the 3 business subnets, and my own test subnet), and to that I added the "single computer" multicast address of 239.255.255.250... but it didn't help any.

I then disabled the Norton firewall on my local laptop and one computer in the other subnet, but this did not result in my getting the other computer to show up in my Network view; nor did my computer show up in the other computer's Network view.

Next logical thing would seem to be to run tcpdump -- tshark -- on the computers and see what they actually do capture. But I've apparently misconfigured my Wireshark install here and I'll have to fix that first...

After finally finding a page to tell me that I needed to start the NPF driver (it was loaded but stopped), I managed to capture WSD packets using WinDump on my laptop PC. But those packet captures do not result in an updated Network view. The only logical conclusion is that there is some obscure registry bit that must be twiddled to make this work. Seeking another needle in haystack... Thanks, Microsoft!

The "Network Discovery" firewall exception must be enabled on the test host

So perhaps windows built in firewall needs to be looked at

According to my W10 installation on the laptop, Norton is supposed to be managing these settings.win_def_to_norton

Big question is whether control reverts to Windows Defender if I temporarily disable Norton. Seems kind of asinine, but perhaps that's just par for the course from Microsoft these days.

We are now well outside my knowledge base, I work hard to be Windows ignorant ;-). In my house we have 5 Debian Linux machines and 1 MacOS laptop for my wife. My laptop does dual boot but every time I boot windows (2 or 3 times a year) it takes something like 24 hours to complete all the updating. So asinine seems par for the course.

2 Likes

@dlakelan: Consider yourself fortunate to have the luxury of being Windows ignorant! Wish I were in your shoes! I have personally avoided going beyond W7 until this laptop came into my possession (as a gift) recently. Still not sure I will migrate over W10 next year (when Microsoft orphans W7) on 3 computers running W7-64 bit.

After all this work, it seems like the Holy Grail is within view but still not within reach. Will keep plugging and update here if/when there's a break...

Yep, I'm fortunate. I think you're getting the packets where they need to be, so I'm hoping it's all going to work once the filtering is figured out! Please do let us know!

EDIT: also, you can test if WSD works at all by putting two W10 laptops on the same subnet and seeing if they see each other. If they do, then at least they aren't completely blocking discovery.