I don’t know if it is worth mentioning, or if it is relevant to mention that this installation is:
GREEN+RED+BLUE+ORANGE
I will try a fresh install of core 153 the next possible time windows, (i.e. tomorrow pm in Quebec). Hardened lock down and curfew are making testing more difficult: this is a production box and I dont have spare pc.
I plan to perform a fresh install and then restore config from backup. If the problem persists, I will redo a fresh install and test to see if zoom works. If it does, I will try to see which configuration brakes things. Will give feed back of this as soon as possible.
As a follow up of todays tests. Doing a fresh install of C153 and restoring step by step configuration and packages let it appear that guardian was the culprit, at least on the fresh install, since on the upgrades install, disabling guardian did no good.
For us, the work around, at least for the time being, is to disable guardian. It is more acceptable then remaining with C152. I reported the tests in detail on Bug report 12563 .
@clgedeon: I have never used Guardian and Core 153 did not work for Google Meet.
MS Teams and Zoom via the Desktop always worked for us on Core 153. Perhaps Guardian what was blocking your Zoom access, but the issue is different from those who cannot access Google Meet and Discord after moving to Core 153.
Guardian - Disabled
IPS - Disabled
Location Block - Disabled
Web Proxy - Disabled
URL Filter - DIsabled
Quality of Service: Disabled
P2P networks - Enabled
Addons: hostapd
Firewall Rules - Default with the following exceptions:
Two rules to allow BLUE clients to access services on a local server on GREEN.
I have MAC Address filtering on BLUE disabled and I block BLUE access to IPFire Web Interface per Blue Access wiki page.
Again all things equal, on Core 153 video camera would not transmit to other clients on Google Meet via Chrome or Firefox, then when falling back to Core 152 everything was restored and working as it has been for years. Again, I haven’t modified my configuration since 2018. I just update with each release.
Bad news today. @rivalblue is right! I received an email from inside LAN that problem reappeared again this morning between two LAN connected client of a zoom session. Yet I was also told that a zoom meeting this afternoon between 2 pc one inside and one outside was ok. I have no more ideas on how to debug this.
Fortunately, I had installed C152 on a spare disk, and it is still there. We will revert to it. But I have saved all logs and will try to see if I can find a clue. Yet I am not a specialist.
Ok. I will do my best. Now we reverted to C152. I must first find a time window where I can do testing. Not before tomorrow night, il there are no zoom sessions scheduled. Otherwise, I will be able to do testing thursday pm.
The weird thing is that nothing special appears in the message log. I really dont know where else to look.
@jon: No, my wife could not connect with her students and other faculty over Google Meet which were not on the same local network. Her camera was functional on her side, but no video would go through to the other clients.
The company I work for uses Microsoft Teams and that was fine. My wife also successfully communicated with friends over Zoom. We also were able to video chat on the same network over Signal with no issue.
We found that clients outside the network were able to hear her audio on Firefox, but still no video - Chrome couldn’t even send audio. The same was true when we started troubleshooting together on Google Meet sessions together on the same network.
My initial kneejerk reaction that this might have something to do WebRTC was due to the fact that I read that Chrome bundles audio and video over the same channel (ICE Candidate) where Firefox uses separate channels (ICE Candidates) for audio and video.
After troubleshooting for a few hours I needed to get her connected to her students again - So I thought about what changed on the network since the Christmas Break and the only thing I had updated was IPFire from Core 152 to 153 and so I backed everything up via the Web Interface and dd-ed a USB Drive with Core 152. After I installed Core 152, reinstalled hostapd, and then restored the backups for both - I jumped in a Google Meet with her and we could see and hear each other again regardless of browser on the same local network. She could also communicate with faculty and students outside the local network without any problem.
I hear you! I do understand 152 works as expected and 153 does not. But for the Devs and people that tested it (like me) all works OK for Core 153. So right now things don’t make sense! I was hoping a LAN to LAN Zoom meeting was the key for the Zoom issue.
As I mentioned in an earlier post Zoom videoconferencing and MS Teams videoconferencing work perfectly for me.
As for Micheal (documented in bugzilla) all works OK with Zoom.
So we keep trying different things until we find the right combo that points us to a fix.
Core 153 started being updated near Oct 27, so there is a long list of changes.
Some feedback of the tests I performed yesterday. Well, I was totally unable to reproduce the problem that was reported to me (two lan computer unable to see each other in a zoom session).
I decided to suspect a hardware intermittent failure as it is rather old (~12 years). Since we have for now, because of mandatory remote work, a number of unused, more recent and more powerful desktops, I decided to temporarily move Ipfire’s disk and nics in one of them. I guess that if nothing nasty happens within two weeks, we can conclude in hardware failure, at least in our case.
Note however that the bogus behavior was consistent for more than two weeks on the upgraded version, that we don’t have anymore… But maybe an upgraded install can be unclean, or the upgrade process not perfect.
Update from my side: I finally got some time to set up my VM test bed, but couldn’t reproduce the problem.
I used my backup ISO from Core 152 to create a VirtualBox VM with Green connected to an internal (simulated) network and Red connected to a normal NAT connection. I then connected a regular Ubuntu VM to the internal network so that my IPFire VM was in its path to the Internet, and attempted a Meet call (to my phone), which was successful. I then upgraded the IPFire VM to 153 and tried again, and the Meet call was successful again. I tried again after adding Guardian, but got the same results.
I’m still on Core 152 on my actual firewall machine right now, but I’ll try the upgrade again some time soon and see if I still have the issue. I’ll also keep the VMs around for a bit, so if you have a suggestion on something to try with them, I can give it a shot.
For the moment, here are the PCAP files of the DTLS failures I was seeing when I was running Core 153, and a success case after rolling back to Core 152. (These files have been scrubbed/anonymized with TraceWrangler. If you are an IPFire developer and need to see the originals, feel free to contact me directly through email.) If needed, I can attach them to the Bugzilla ticket as well - let me know if that would be helpful.
I have the same issue… in LAN we can use video but with people in other side of the red interface there is no video.
Apps that I tested, zoom MS Teams
Simple conf with 4 zones (Green, Red, Blue, Orange) and only outgoing rules for all that zones…
If I publish one service inbound some times it goes fine…
Im rolling back to 152 since I need the share screen to work!!!