My outgoing rules are default. Actually, I only have two firewall rules which are “DMZ Pinholes” to allow clients on Blue to contact a server on Green.
I don’t enable QoS, IPS, or Web Proxy. My firewall is quite close to default. For example, I only use a single add-on: hostapd.
I have happily used IPFire for years and I haven’t made any changes to my configuration since sometime in 2018, but then after updating to Core 153 - Google Meet suddenly doesn’t function. When I dropped back to Core 152 everything functions fully again. Nothing was in the firewall logs showing that anything was being dropped between the clients and the Google Meet servers.
I firmly believe there is a bug lurking somewhere in Core 153. It seems to have impacted at least three users at this point - @prussbw, @soundconjurer, and myself.
Could you please raise a bug then. Your IPFire People login credentials work on Bugzilla as well as IPFire Community. Following wiki link gives info about raising bugs. https://wiki.ipfire.org/devel/bugzilla
Have you blocked some coutries via location block or block p2pnetworks. (This are the 2 functions that blocks connections without logging, all other should add log entries.)
For example blocking “A3 Worldwide Anycast Instance” may block some goolge servers.
I have no idea wich part of core153 can block a single service.
It is huge but this is because the kernel and microcodes are shipped with this update.
Here a list of all changed parts:
It isn’t a single service - Multiple others have said they have issues with Discord as well after Core 153. At least one user (@prussbw) has downgraded back to Core 152 and they have confirmed Discord functionality was restored.
I dont think so because I have installed core153 and use Nextcloud talk which also based on WebRTC without problems.
WebRTC use simple DTLS and SRTP streams which IPFire only sees as UDP connections.
But there is a problem with UDP behind NAT. Some protocols need a special NAT helper if there is more than one client that use the same protocoll behind the nat. Im not sure if there is something changed with this helpers in core153.
One thing I can confirm is that in both the Meet and Discord cases, STUN was in use for NAT traversal - I can see the session messaging in the trace.
I can also confirm that my firewall rules are also near-default. The only rules I’ve created are to block access to the IPFire Web UI from my Blue subnet.
It seems possible that the NAT traversal might be affecting the outgoing DTLS handshake message in an unsupported manner, causing it to fail integrity/authentication checking at the receiver’s side. I’ve seen similar cases in things I’ve worked on in the past, but I haven’t had time to create a test bed to verify that theory. (Meet is non-negotiable for me for work reasons right now, so I have to stay on 152 until there’s either a fix or a workaround.) Any test bed I setup would have to be VM-based, so hopefully that would be sufficient to prove this out.
I agree that there should be a bug logged for this, but I’m not sure how well-characterized you need it to be. (We’ve already seen that Meet is working for some others, so I don’t want it to become closed as could-not-reproduce.) Let me know if you have any recommendations along those lines.
In our LAN, this problem with core update 153 also affected communications with zoom meetings, fb messenger and whatsapp eversince it wath applied on dec. 22d. When client connected from inside LAN, people outside lan would only see a black screen, but audio did however work.
Resetting modems, switches, did not help.
Stopping Guardian, IPS and Location block (the only services that we use) did not help either.
We noticed however that videoconferencing through web browser did work, using jitsi or whereby
Reverting to core 152 last monday solved the problem and now all videoconferencing clients of various types work again…
I have core 153. I just signed up for a Zoom account, installed the Zoom app on my iMac, and did a 5 minute video call with my son (he is at work). All worked A-OK on both sides. I did not try the Zoom browser version.
Jon iMac → IPFire → Cable Modem → Internet ->> Son at work
So maybe there is something configured differently in the IPFire box??
My side:
Guardian - No
IPS - RUNNING on red only.
Location Block - enabled
Firewall Rules - all off except for DNS/NTP redirect (testing)
P2P networks - all disabled (not checked)
Default firewall behaviour - FORWARD & OUTGOING is Allowed
Web Proxy - Transparent
URL Filter - not enabled (not checked) EDIT: Quality of Service: RUNNING
@jon: FWIW Microsoft Teams and Zoom worked for us via the desktop on Core 153.
For us it was that Google Meet was not running fully via the browser. On Chrome, it was not transmitting Video and Audio and Firefox would transmit Audio to other users, but no Video. Before anyone suggests it was a browser setting, we ran our tests on default profiles (no add-ons, factory settings, etc.) to ensure nothing funky was going on with browser settng or add-on. It was only when returning to Core 152 where functionality was restored.
My wife is working from home and using MS Teams (and sometime Zoom) during the entire day. All is working A-OK with core 153. That is why I mentioned this:
We may need to look at the differences in setup to figure out what went wrong…
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.