T-Mobile Wifi Calling Help

iPenguin

I been plagued with service issues with T-Mobile for the longest time. Even Wifi Calling is poor. After speaking to a T-Mobile tech, they suspect an issue on my end. I did some searching an made some changes to my pfSense, but I'm not 100% this is all that needs to be done. I'm still new to pfSense and still learning. Any help would be greatly appreciated.

Phones: Androids - Samsung Note 20 Ultra and Samsung S20

In a few of the posts on this forum, I found that people set the following:
Under System > Advanced > Firewall & NAT

Set Firewall Optimization Options to Conservative
Checked Disable Firewall Scrub

I also disabled ISAKMP based on this post https://forum.netgate.com/topic/152744/tip-i-solved-my-wifi-calling-issues and setup the 4500 ports.

So my outbound looks like this

johnpoz

I'm on t-mobile - and just tested wifi calling and don't seem to have any issues with it. And I have done none of those settings. firewall scrub is on for sure. And have not done anything with outbound nats - they are also auto.

To test wifi calling. Validated that it was on it settings, and that my e911 address was listed.

Then turned on airplane mode. Then enabled wifi. So cellular service is OFF. Wifi is on..

Then made a call - worked just fine.

S762

FWIW we just switched to MintMobile two months ago from Consumer Cellular, Mint rides on the TM network. I use WiFi calling all the time in the house and never had an issue. here’s my settings

Outbound NAT Mode is set to Automatic outbound NAT rule generation.
Firewall Optimization Options – Conservative
Disable Firewall Scrub – unchecked

Generally I wouldn’t even be in the advanced section but a few years ago on the previous ISP we were having issues with VoIP call quality and I read somewhere to change a few pfsense settings, as I remember the Firewall Optimization Options was one on the tweaks. Looking back I think the issues were with the prior ISP itself. Anyway we switched ISP’s again last June and never bothered to change that settings.

Using a Linksys EA8500 running dd-wrt in Access Point mode and I have an Samsung 2017 Galaxy J7 connecting on the 2.4GHz band.

lohphat

@johnpoz

I'm on T-Mobile too and things initially work but sometimes during a long call the connection drops and the remote party say there was a "squeeling tone" then the call dropped.

Could it be IKEv2 rekeying? Also, Verison users also report need to allow UDP 4500 in addition to UDP 500.

How can the default rule be duplicated to add port 4500?

https://community.verizon.com/discussion/914293/network-ports-to-enable-wifi-calling

stephenw10

Connecting then failing after sometime is unlikely to be a static port issue. However you can try adding static port outbound rules for port 4500 as shown above.

aivxtla

@lohphat I’m on T-Mobile and have Verizon Fios, I haven’t made/needed any such tweaks. NVM you meant Verizon for wireless.

lohphat

@stephenw10 What about IKEv2 renewal from the remote side? Isn't that an issue in general with IPsec (which is what wifi calling prefers to use).

stephenw10

It's possible to have a situation where an IKEv2 tunnel connects initially but fails at renewal because it uses the P1 encryption details for both P1 and P2 until renewal. But that's nothing pfSense can affect in this situation.

Try adding a static outbound NAT rule for udp port 4500. It shouldn't change anything but it also won't hurt unless you have multiple devices trying to connect to the same server address.

lohphat

@stephenw10 Hmm...that's going to be a problem as multiple people are behind the FW using wifi calling.

I need to keep hunting down the cause. The other behavior is I miss inbound calls occasionally -- straight to voicemail. But I disable wifi calling and calls aren't missed.

It's as if the wifi calling IPsec session is getting stale and not renewing.

stephenw10

Check the states. See if you can catch the tunnel failing.

Though I would expect if the tunnel goes down though then the phone would fall back to not using wifi calling. So it would have to think the tunnel is still up whilst also being unable to send traffic across it.