Remote user sees no Bonjour

I have defined a VPN tunnel over PPTP to allow users on the WAN to login locally to our LAN.

Most of it works. Remote users can ping LAN hosts, connect to internal file sharing servers, and connect to internal websites, including the configuration screens for internal printers and routers.

What doesn’t work is the Bonjour protocol. it works fine on the LAN side of the interface port, but not over the remote tunnel.

Although the remote user can access local servers and local printers if he knows their IP address, they don’t come up automatically in the advertised list and they can’t be referenced by host name. Local chat users do not show up in the iChat window. Local hosts offering screen sharing do not show up in VNC clients (although if you know their IP numbers, you can access them fine).

I’ve slapped proxy_arp on every involved interface I could think of, but no joy. I played with /ip upnp, defining the interfaces, trying both dummy-rule and allow-disable in both the on and off positions, but it makes absolutely no difference.

Is there any way to get Bonjour to work over this interface?

seems like it’s all broadcast traffic. so, you need to establish, for example, EoIP tunnel and then bridge it with your ethernets

I don’t have two Mikrotiks here. I have one Mikrotik, and a remote user located somewhere on the internet who is establishing a PPTP VPN connection into my Mikrotik from his PC/Mac in order to access my LAN.

Bonjour is mostly multicast. So either set up multicast across the tunnel, or force the machine on the other side to use the central Bonjour enabled DNS server on the LAN when on the VPN. OS X 10.4 introduced dynamic DNS that allows unicast Bonjour to work, but of course the client must then actually ask the server specifically.

Or buy a second RouterBOARD to put the remote client behind and use an EoIP tunnel as Chupaka suggested - that would also forward multicast, and Bonjour would work as usual. That also gives you other options for managing the remote side of the tunnel, and you can use the firewall that you’re already used to and protect the remote machine.

Second RouterBoard is a nogo. This is for situations like traveling.

I appreciate the tip:

I tried setting the only DNS on the remote Mac’s VPN to be the LAN interface on the Mikrotik. It didn’t seem to have any effect. I don’t have an actual DNS server on the LAN, I am just using the SOHO version of Bonjour.

I read elsewhere that

You might at this point wonder how this works on a local network without explicitly setting up a DNS server or domain name. That’s where multicast and the “local.” domain come in to play. Bonjour includes what amounts to a smart DNS server/client/cache that runs over multicast (method of broadcasting traffic rather than sending it to a specific machine, generally limited to a local network) which combined with the convention of using the “local.” domain allows these DNS records to be served and retrieved without a DNS server…. If you’re relying on multicast-based Bonjour (the ‘just works’ on a local network Bonjour) then probably not as most VPN connections won’t pass multicast traffic.

So your tip about “set up multicast across the tunnel” seems like the most attractive option if it works. However, I’m not sure how to do that. I looked up multicasting in the manual and was swamped with information about some PIM protocol. I tried simplistically adding both the LAN and remote login interfaces to /routing pim interface, but it had no apparent effect.

Can you elaborate as to how I add multicast to the remote login PPTP VPN interface? I would appreciate it.

If you don’t have a dedicated name server on the LAN then the unicast option is indeed out.

I have to admit I’m shaky on multicast. I believe that since you have a rather simple set up IGMP proxying should do fine for you.
http://wiki.mikrotik.com/wiki/Manual:Routing/IGMP-Proxy
That link contains an example section - follow that, and set your LAN interface as the upstream. Ensure that when the PPTP interface shows up as a dynamic interface like ether2 and ether3 do in the example. If it does not, try adding it manually and explicitly.

However, that still depends on the client on the other end actually processing multicast received via the PPTP tunnel (it might not, I don’t know) and sending multicast traffic into the PPTP tunnel (it might not, I don’t know). That isn’t something you can fix on the RouterBOARD as it would be a limitation of the tunnel type, or the client VPN software stack.

Today I see a thread that confirms that what I want cannot be done.

Reason: Bonjour will not allow TTL > 1, and uses a link-local address that will not transport outside L2.

So this feature will never work in RouterOS unless MikroTik includes an avahi proxy package or equivalent.

Now at least I can stop being bothered by the fact that I have been unable to solve this problem.