WiFi Calling and Push Notifications problems

[eicastic1]

I have a new install of the newest version of OPNSense (as of this posting date). I have two issues I can't resolve. First is that my mobile devices (androids) do not receive any push notifications. And second, most of the time I am not receiving cell phone calls over wifi--the phone never rings and the caller goes straight to voicemail.

Both of these worked perfectly fine on a Netgear r6700v2 router that this OPNSense build replaces.

I am not using IDS or IPS. I am not using IP6. Firewall setting was changed from Normal to Conservative. I have 16GB RAM and a beefy processor, the state table is never close to getting full (I only have about 40 devices behind the firewall, most are low traffic). I have UPNP enabled for two XBOXes.

I see rejections on the WAN interface stating "Default Deny / State Violation Rule" for things that appear to be push notification services (IP belongs to google or amazon coming in on port 443).

It's my understanding I shouldn't need to open any ports to enable my devices to receive push notifications or receive wifi calls. I didn't have to open ports of the old router for this. Since this is stateful it should be looking at the state table and allowing the push notifications in, correct?

I don't see anything in the forums or reddit on this issue for OPNSense. General queries aren't very helpful (PFSense had a thing for wifi calling to up the timeout of UDP sessions, which led me to the "conservative" firewall setting in OPNSense). And for push notifications there are mentions of various ports depending on the service, but that's the wrong path for a stateful firewall (and again not something I had to do on the previous router).

Any help would be appreciated. If I can't get this resolved I will have to drop my build and revert to the R6700 router which I prefer not to do if possible.

Thanks.

[EdwinKM]

Not really experience. But a guess

Opening ports i would not expect. Your phone probably does regulary a connection to the destination to keep the connection "alive". This results that the destination can "call" at any time.
Without such "alive" events the firewall state will timeout and the destination is not allowed to send anymore. Like this dude says: https://superuser.com/questions/1588681/why-do-push-notifications-work-with-incoming-connections-blocked-at-firewall-lev

As you point out "most of the time". Sounds like it works in the beginning and break later. So i would expect the connection dropped later on. Sure, nothing else configured which can block this outgoing calls? (dns?)