Cross VLAN Connections - Connects, but no audio. (OPNSense and UnRaid) #312
Comments
|
No restriction. It's probably a firewall problem |
|
Might be right. I thought it was just Apple Music, but just tried PocketCast and the same issue. Volume “beeps” are being passed to my chrome cast audio. Not sure what changed in the past week. My router/firewall is OPNSense and I’ve been using MDNS Repeater so that my IoT devices on the untrusted wifi can broadcast to the trusted wifi. I’ll try joining the the untrusted wifi to see if issue remains. |
|
Firewall doesn’t show anything being blocked to/from the chrome cast audio. |
|
How does AirConnect run? What OS/CPU? container? |
|
UnRaid 6.8.3 |
|
Can you post a log? I still suspect it's a NAT/firewall |
|
|
Also saw these in the UnRaid logs. Dec 11 15:36:28 HomeServer kernel: br-ca10b681aed9: port 4(veth70eaa5d) entered forwarding state |
|
There is a log created by aircast. I don't know where this docker image puts it. If you can't find it, can you manually start it? Seems to me that @1activegeek is providing explanation on how to do that. Just run ./aricast-x86-64 -f , try to play something and then zip & attach logfile. It will tell me a log of what's happening |
|
Got the logs. Stopped container, started, ran debug command below, and started to stream using PocketCast to bedroom speaker aircast-x86-64 -d all=debug[10:39:59.868656] main:958 Starting aircast version: v0.2.41.0 (Dec 8 2020 @ 18:41:57) |
|
Correct, there is actually a way to run the container with a command to input the debug mode. Not sure if that command gave what was needed, but you can use the following as an example of how to run it:
Would run the above that you indicated. I see it was also mentioned to run with
This should drop you to a terminal within the container, and allow you to try and kill or terminate the process, make changes as necessary, and then exit and restart the container or even manually run the command with the binary itself. May require using |
|
Thanks @ 1activegeek here are the logs from your instructions Last login: Sat Dec 12 09:20:52 -0500 2020 on /dev/pts/0. |
|
I just did another test. I thought I had ALL of my Nest/Google speakers on my untrusted network (10.0.3.1/24). But I actually had two of them on my trusted network (10.0.1.1/24), the. Ultra and Nest Mini (kids room). The ChromeCast Audio was on the untrusted network. Streaming to Trusted from Trusted works. Streaming from Trusted to Untrusted does NOT work. Streaming from untrusted to untrusted does NOT work. So looks like these IS a firewall issue, just not sure what changed in the past few weeks, firewall and VLANs were set up like this for months. |
|
Here are more logs for the previous test. still think its a firewall issue, but happy to have the DEVs review and if they concur we can close this issue. Thanks [18:37:58.299480] mDNSsearchCallback:405 [ACTIVE] host 10.0.1.7, srv 10.0.1.150, name Google-Nest-Mini-2147c4e73005c5cf3e0091ce5b3d4b45._googlecast._tcp.local [18:38:01.032368] handle_rtsp:405 [0x153948017e80]: received SETUP [18:38:01.033464] rtp_request_timing:860 [0x15394c005ed0]: timing request now:2651908765 (port: 54617) [18:38:01.038423] rtp_thread_func:841 [0x15394c005ed0]: Timing references local:2651908765, remote:83ba64d7d83b1af3 (delta:0, sum:0, adjust:0, gaps:0) [18:38:01.086379] flac_init:220 [0x15394c005ed0]: Using FLAC-0 (0x153944000b20) [18:38:01.090320] rtp_thread_func:841 [0x15394c005ed0]: Timing references local:2651908818, remote:83ba64d7e58ea44f (delta:1, sum:-1, adjust:0, gaps:0) [18:38:01.231230] handle_rtsp:405 [0x153948017e80]: received SET_PARAMETER [18:38:01.582085] rtp_request_resend:896 resend request [W:22606 R:22543 first=22607 last=22607] [18:38:02.292415] handle_rtsp:405 [0x153948017e80]: received SET_PARAMETER [18:38:02.466745] CastSocketThread:728 [0x695d30]: type:MEDIA_STATUS (id:0) (null) [18:38:02.897560] handle_http:1313 [0x15394c005ed0]: responding: HTTP/1.0 200 OK [18:38:02.897569] _buffer_get_frame:983 [0x15394c005ed0]: drain [level:220 gap:-60] [W:22763 R:22543] [R:1 S:0 F:0] [18:38:06.546066] read_line:1219 disconnected on the other end 22 [18:38:09.819470] handle_rtsp:405 [0x15394801b450]: received SETUP [18:38:09.823132] rtp_thread_func:841 [0x153940005eb0]: Timing references local:2651917552, remote:83ba64e0a1388ca3 (delta:0, sum:0, adjust:0, gaps:0) [18:38:09.828714] handle_rtsp:405 [0x15394801b450]: received SET_PARAMETER [18:38:09.832757] rtp_thread_func:759 [0x153940005eb0]: 1st sync packet received [18:38:09.896830] handle_rtsp:405 [0x15394801b450]: received SET_PARAMETER [18:38:09.901768] handle_rtsp:405 [0x15394801b450]: received SET_PARAMETER [18:38:09.905195] handle_rtsp:405 [0x15394801b450]: received SET_PARAMETER [18:38:09.909031] handle_rtsp:405 [0x15394801b450]: received SET_PARAMETER [18:38:10.415941] raop_cb:209 [0x6966c0]: Play [18:38:11.082179] handle_rtsp:405 [0x15394801b450]: received SET_PARAMETER [18:38:11.478791] CastSocketThread:731 [0x6966c0]: type:RECEIVER_STATUS (id:1) |
|
Closing. Firewall rule to allow certain ports from the untrusted LAN to hit the trusted LAN. Screenshot below. All is working.
|
|
BTW, since version 0.2.40.x, you can limit the ports AirConnect uses |
So I’d be able to limit that second rules ports? Is there a best practice of how many ports to open for a certain number of devices? Or does that not matter since each device has a unique IP. |
|
I've updated the README to give better guidance |
|
This look right for the custom config.xml? Idea being to restrict usage to 150 ports. Does the custom config need the device sections or can those be added dynamically? |
|
Also just tried manual running app inside the container w/ the -x flag and got "no config file, using defaults". The file is there.....if this is just me not understanding a concept I'm happy to be directed to a resource to study. Thanks again. |
I believe you are missing a closing IIRC - the advice is to run the command a certain way to generate a proper config format, then you can modify or add/del/etc. This may be the best course to get a fresh file? |
|
My file has the closing tags (at least I think it does, not home right now). The part of later was just the common section before the device specific info. |
|
Are you sure the config.xml is in the root folder? That seems odd. I know it's a bit strange but it's not first-port:last-port but first-port:count :-) (and you can also set that on the command line, don't need a config file). |
So you were partly right :-). I did create my original config using the -I command, but during my (bad) testing I tried to delete the device section of my config and forgot to re-close the section. I have done that and now the config file is accepted. PLUS I just saw @philippe44 response about the config file and the ports being port#:count so I've changed it to 60100:150. Lets see what happens. If that works then I'll just try to use the flag instead of the config file since that's the only change I'm making. |
|
@philippe44 |
|
The config is fine but not the command line as the brackets [] are a syntax to indicate an optional parameter, but should not be part of the command (I've just clarified that in the README) |
Gotchya, so when trying to run w/ -a 60100:150 each render gets a cannot bind error. I get this error no with either firewall rules enable (restricted to 60100 to 60250 or 32788-61000). If I run the program w/o the -a flag and port, then everything binds fine (regardless of which firewall rule is enabled). |
Flyinace2000
changed the title
|
Maybe I'm misunderstanding something. A few sources online say that chrome casts need Port: 32768 - 61000. Would this requirement not be change by using AirConnect? If that's the case, then no real reason for me to have AirConnect (or my Firewall) restrict which ports to use. |
|
I'm not sure about the specifics of that port usage for Chromecast, but what I will say is that with the added complexity I just saw in the title change (Cross VLAN) - I can tell you there will be difficulty. In most routing setups, handling the UPNP nature of the chromecast devices is troublesome at best. Hopefully OPNSense can be better - but I honestly can't even remember the hoops I jumped through to get mine working. I still can't get to my Chromecasts from my phone when on my secure network, connecting to IoT network on a diff VLAN. I have to connect to a diff wifi just to config them. Just my 2 cents about the head banging you're probably doing about this all. 😄 |
|
I guess the question I have is what does the port flags (-a or ) do from a functionality perspective. Do they define what ports your program uses to communicate to the device sending audio, or the ports the chrome cast receivers will use? I am suspecting is the ports AirConnect will use. On my network AirConnect lives on UnRaid on the trusted VLAN1 (10.0.1.1/24) and the chrome casts on the untrusted VLAN20 (10.0.3.1/24). My devices that send music (phone, and MacOS desktop) are on the trusted VLAN. I was understanding the port flags/config to designate what ports the chrome casts would use to communicate. So when I restricted the ports to 60100:150 (60100-60250) and then enabled the firewall rule to only let through 60100-60250 from VLAN20 to VLAN1 I can connect to the chrome cast (and change volume), but streaming audio did not work. But when I change that firewall rule to let through 32768 - 61000 everything works. Here is my current config to enable cross VLAN audio streaming (trusted to untrusted) using OPNSense and UnRaid Firewall Rules UDP Broadcast Relay |
|
The -a is really for the incoming (listening) ports I'm opening. I don't set the outgoing port explicitly and that might be the issue. Now, I might have left errors :-) |
|
Coming back to this myself as I finally got around to fixing and fully isolating some networks of my own and wanted to share some inputs in case anyone is using my container and/or similar setups - they can take most of what is shared here. Infra:
Traffic Flow (per @philippe44 guidance in this issue: Since the traffic is ACTUALLY pulling from the Google Home device, it is pulling from the ports that AirConnect is publishing. Due to the updates made, we can now control what these ports are so as to not require broad open ports. Using the
Once this is done, add the rule, and ensure that if you have any other rules in your firewall that would block this (i.e. a Block IoT traffic inbound to LAN) that you re-order your rules to have this one applied ABOVE those rules. The best option will be to place this rule directly above the IoT blocking rule. Once I finished doing this, I was able to stream Apple Music from my iPhone directly to the Google Home Mini devices inside of my network. Originally they had the same issue described above (controls would work, no audio) - this fixes that and narrows the scope of traffic to ensure that no broad port rules are needed to open from the IoT VLAN to your trusted VLAN. It also helps reduce the scope of IP as well by designating only the particular IP of the AirConnect server. Thank you again @philippe44 for the great work, and adding in the port control option enabling this to be easier. And also thank you to @Flyinace2000 for helping flesh this out before I had to 😛 saving me some time I'm sure. |
Is there a restriction on casting Apple Music. It starts the cast to both my Nest Mini and Chromecast Audio but no sound comes out. I’m running AirConnect on my UnRaid server via docker. iPhone is 12 Pro on iOS14
The text was updated successfully, but these errors were encountered: