[SOLVED] How to enable Chromecast/Airplay across VLANs in the ER605 in standalone mode

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

[SOLVED] How to enable Chromecast/Airplay across VLANs in the ER605 in standalone mode

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
[SOLVED] How to enable Chromecast/Airplay across VLANs in the ER605 in standalone mode
[SOLVED] How to enable Chromecast/Airplay across VLANs in the ER605 in standalone mode
2024-05-11 22:50:29
Model: ER605 (TL-R605)  
Hardware Version: V2
Firmware Version: 2.2.4 Build 20240119 Rel.44368

I found it hard to find how to enable Chromecast across VLANs on my ER605 V2 in standalone mode by just Google searching.  Most others reporting success here and on Reddit were using Omada – not that it should have been all that different.  Although many show "EAP ACLs" - the only ACLs I can find to set in standalone mode are in the router (gateway).  I worked it out in the end so I’ll share my findings and implementation steps here for the benefit of anyone else trying the same with devices in standalone mode.

 

TL;DR

Needed to add UDP port 5353 (mDNS) as a service type, add an ACL from the device network to the router for the new mDNS service (as I had non-trusted networks blocked from the ER605), and _googlecast._tcp as a mDNS service.  Only that last point was easy to find from searches, the first two points were the tricks I had to work out.

 

 

Full details:

 

I have:

  • An ER605 V2 router (Firmware Version: 2.2.4 Build 20240119 Rel.44368)
  • A couple of EAP650 edge wireless access points (also in standalone mode)
  • Non-Omada TP-Link managed switches that support VLANs

 

The equipment was all working fine.  Numerous VLANs working fine (through both the switch and EAPs).  Not using Omada – “why not?” explained later – all devices in standalone mode.

 

But I wanted to isolate my Google Home devices, including casting devices on their own VLAN (name = “DevicesNet”, id = 20) yet be able to cast to them from the main VLAN (name = “MainNet”, id = 1).

 

 

STEP 1: Add a service type for mDNS

 

Preferences > Service Type > Add

 

Name: mDNS (or whatever you want)
Protocol: UDP
Source Port Range: 0-65535 (means any)
Destination Port Range: 5353-5353

 

A bit suprised that some ports are missing from the default list.  Most suprising is that HTTPs (port 443) isn't there.  mDNS also wasn't there but arguably it's much less commonly used in user customizations. 

 

STEP 2: Add ACL

 

Firewall > Access Control

 

I had previously blocked access to the ER605 admin page from most of my VLANs.  This is done via an ACL like this:

 

Policy: Block
Service Type: All
Direction: All
Source: !MainNet_Group
Destination: Me

 

People have reported that a rule like that blocks internet access for your VLANs (IoT, Guest Networks, etc) and that is true.  But it’s only because they can’t get DNS information.  So a simple DNS Allow rule with a higher priority ID resolves that:

 

Policy: Allow
Service Type: DNS
Direction: All
Source: !MainNet_Group
Destination: Me

 

That allows my non-MainNet VLANs (which includes DevicesNet) internet access but not access to the ER605 web UI itself.  (Depending on your rules you might need to also add an Allow rule for HTTP and HTTPs [another service type for port 443 needing to be manually added] ffrom the desired VLANs if you want other devices that can administer it.)

 

And really, these rules were the biggest part of my problem setting up the casting.  The solution was an mDNS ACL from the DevicesNet to the ER605 device itself (between VLANs seemed like the obvious requirement to me initially, but that wasn’t the issue).

 

Hence what was required in this condition is a higher priority ACL for:

 

Policy: Allow
Service Type: mDNS (or whatever you named the service type in STEP 1)
Direction: All
Source: DevicesNet_Group
Destination: Me  <----- This was the part that took the longest time to solve

 

That was the critical piece missing in my implementation.  The remaining steps were easier to work out.

 

BTW, the DevicesNet network is blocked from the MainNet but not the other way around (a fairly typical configuration).

 

 

STEP 3: mDNS Configuration

 

Services > mDNS > Add (in the “Services” section):

 

Name: Chromecast (or whatever you want)
Domain: _googlecast._tcp

 

No need for a trailing period or for “.local” as you may see in other posts.

 

Then "Add" again, this time in the “mDNS(Bonjour) Rules” section:

 

Description: Google_Cast (or whatever you want)
Service Network: DevicesNet
Client Network: MainNet
Services: Chromecast (or whatever you named it)

 

Enable “Multicast DNS Repeater” and voila - Chromecast works across VLANs!  With this current ER605 firmware version, there was no need to make the Service and Client networks “All” like others have posted due to bugs with older firmware versions.  It can be limited to just the two VLANs I want.

 

If required, you can also add Airplay to the same entry.

 

Anyway, hope those details help anyone else in a similar situation.

 

---

 

Final point: why am I not using Omada?  Well really two things:

  1. My switches are TP-Link managed switches and do the VLAN’ing I need, but are not Omada compatible.  I would have loved to have Omada switches as well but the price difference was just too much.
  2. I already spent a lot on this hardware so didn’t want to purchase the controller at this time.  And I’d prefer to have a hardware appliance (the OC200 controller) than use the software version.

 

And, while I found it a little tricky to setup this Chromecast configuration, I am getting by with all devices in standalone mode (i.e. I just backup the config from one EAP650 and restore it to the other).

 

Now if someone can convince me why going to Omada (without replacing the non-Omada TP-Link managed switches) would be a good idea, I’m all ears.  ;-)
 

  2      
  2      
#1
Options