OPNsense Forum
Archive => 18.1 Legacy Series => Topic started by: seamus on February 16, 2018, 07:57:39 am
-
My remote OpenVPN clients are all Macs (as in OS X). My LAN is an eclectic mix of Windows clients, a DC/server, NAS units, the odd Linux box, etc. I used Avahi some time ago on pfSense, and it seemed to work pretty well. I've read that Avahi is not available for OPNsense (and why), and that mDNS is a 'functional equivalent'. And so I've installed mDNS, and configured it to listen on the LAN and OpenVPN ports. However, after a few hours, I'm not seeing my Mac VPN client pick up any of the devices on my LAN that use Bonjour (other Macs, Time Capsule, etc).
One suspect: Under General Settings for Domain, the following caution appears, but its meaning is unclear to me:
"Do not use 'local' as a domain name. It will cause local hosts running mDNS (avahi, bonjour, etc.) to be unable to resolve local hosts not running mDNS. e.g. mycorp.com, home, office, private, etc."
My "local"/LAN domain is 'MyNet.local' - it's been this way for years, and would be a terrific pain to change.
Where would I begin looking to try to sort this out? Hey - I thought this was supposed to be "zero-configuration" networking :)
-
You may have more luck if you change your VPN from the default tun devices to tap devices. You need to make the change at both the server and the client. If you want to test with just a few Macs, you'll need to run a second OpenVPN server on a different port or IP address.
https://community.openvpn.net/openvpn/wiki/BridgingAndRouting
Bart...
-
Aye, it would seem that bridging has its advantages, but then, as it always is, it brings along some baggage that's not particularly welcome - a 'tradeoff' then. I've just looked at the configuration of the pfSense OpenVPN box that I'm replacing, and it used bridging and 'tap' (in addition to Avahi). It was configured by Chris Buechler (shortly after pfSense got into the "service" business), and worked extremely well for a while; which is to say I am confident that your recommendation for bridging with tap devices is sound.
And thank you for the reference to the OpenVPN website; I've read it (and quite a bit more) in an effort to re-acquaint myself with the subject matter.
But I am still quite foggy on why mDNS doesn't help... I was under the impression that it effectively overcame the non-routable aspect of the Bonjour broadcasts; making them available on both the LAN *and* the OpenVPN networks. Otherwise, why specify two interfaces? Is there a reason why mDNS doesn't reach my Open VPN clients?
-
Have you tried the os-igmp-proxy plugin for your remote clients to join the mdns multicast groups?
Bart...
-
Have you tried the os-igmp-proxy plugin for your remote clients to join the mdns multicast groups?
No, I'd never heard of it until I read your post. But I will certainly research it, and give it a try - thanks!
Does it depend on tap/bridging or tun/routing - or will it work with either device?
-
The proxy is independent of the tunnel device, but maybe not so useful on taps ;-)
Bart...
-
The m in mDNS means multicast. mDNS is a name resolution system in which there is no central server. All machines receive queries and reply, over 224.0.0.251 port 5353/udp.
224.0.0/24 is a local-only network. It is not routed, as per IETF RFC somesuch.
So either you bridge and there is no network boundaries to cross, or you use a proxy standing on each side of the network border to help multicast packets across. IGMP is the IPv4 protocol used for multicast routing on local networks.
About the .local domain name. mDNS is local in nature, DNS is routed and often public. mDNS records are short-lived, DNS records are usually cached for a while.
They don't mix well, so in order to avoid random mDNS requests leak into the DNS infrastructure, clients are generally set to try mDNS resolution *only* for the mDNS domain name, and try DNS for other domains names.
This is what the help text in OPNsense says: don't use .local as DNS name or mDNS clients won't resolve non-mDNS hosts names because i. these don't respond directly over mDNS and ii. the DNS server will never be queried for them.
Since mDNS is configured locally in so many (ephemeral) clients, changing the mDNS domain to .foobar is impractical. So the simple rule is "don't use .local as your local DNS domain".
-
The proxy is independent of the tunnel device, but maybe not so useful on taps ;-)
OK, so I am trying to figure out how to configure the os-igmp-proxy plugin, but struggling with it. While researching this topic, I ran across an interesting (?) website, in which the author states that multicast is not "built in" to the FreeBSD kernel by default, but can be added as follows:
http://troglobit.com/howto/mrouting-in-freebsd/
Just out of curiosity, is the kernel used in OPNsense built with multicasting capability?
And finally, I'd appreciate an informed opinion: Might I be better off (as in have an easier go of it) skipping this multicast can of worms, and using bridging instead of routing in my OpenVPN server?
-
If you are happy with the extra VPN traffic that a bridge incurs and you have no other issues, then it seems like a moot point to me.
The more you need to tinker to get something to work, the more things that can break it.
Bart...