iPhone WiFi Calling Behind 5268AC
-
Is anyone successfully using WiFi calling behind an AT&T 5268AC? I'm running pfSense on an SG-3100 behind an AT&T 5268AC. The 5268AC has the Netgate in DMZplus mode.
I have three iPhone users who can successfully make and receive calls in WiFi calling mode, but when they initiate the call, the call receiver cannot hear them. Although, the call initiator can hear the person they are calling. All three iPhones exhibit the same symptoms. I have two Android phones who can use WiFi calling flawlessly. This symptom does not appear to occur on Android.
I put the whole network on the 5268AC, bypassing pfSense and the iPhones can use WiFi calling flawlessly. Is there something about how I am connected to the 5268AC? A rule or setting I've missed?
BTW, yes, this is an extension of this thread, but I've narrowed it down to the Netgate or the interface between the Netgate and the 5268AC, so I started a new thread. Also, yes, I've read this thread about WiFi calling not working sometimes. I don't see a solution in this thread and the symptoms are different. In their case, calls and SMS don't connect. In my case, SMS is not impacted and calls always connect. One update from the previous thread, I am now running IPv6.
Thanks.
-
I think I've identified the root cause. I'm still baffled why the only phones that seem to be affected are AT&T iPhones. In addition to the above test cases, I managed to test a Verizon iPhone on WiFi calling, and it worked flawlessly.
I had an explicit deny rule below all of my other rules that read:
- Action: Block
- Interface: WAN
- Address Family: IPv4+IPv6
- Protocol: Any
- Source: Any
- Destination: Any
When I disable it, the AT&T iPhones work fine. When I re-enable it, the symptoms recur. It is now disabled.
Now the question is, do I really need this rule. I was taught years ago to include it as good practice, but recently I discovered Default deny rule IPv4 & Default deny rule IPv6 in the logs that sound like they're doing the same thing but in a more sophisticated manner.
I appreciate your input.
Thanks.
-
No reason that should affect Wi-Fi calling. That is for inbound connections only. Wi-Fi calling makes an outbound IPsec connection to the mothership and all call traffic is tunneled over that.
Removing that block rule would do nothing, based on the fact that all traffic not explicitly passed is blocked by the default deny rule anyway.
-
Looks like I've jumped the gun. For some reason, the symptoms disappeared for a bit, but they are back. Watching the firewall logs (filtered on the iPhone), I see this:
The symptoms persist through this stretch of logs, but I don't see any failures. Where else should I be looking? -
Those are all pass logs and have nothing to do with IPsec.
-
Never tried it yet.
