I have a Netgate 6100 on a clients buisness. The pfsense works great and the resources of the Netgate 6100 always operates nominally even with 600 clients connected. The problem is with WiFi calling. this business’ sits on the side of a mountain with no cell service, so everyone who connects via WiFi or ethernet relies on the Internet access for communication.
With regards to WiFi calling, It works for some but not for everyone, as if the tunnel is closed after several devices have already made calls out or in. SMS texting is the same. I have changed the router to Conservative and disabled the default NAT IPsec (500) rule. But the clients still report phone calls dropping after a few minuets or not being able to receive or make calls at all. I have tried to implement the Default NAT rule (500) and added Pot 4500 and 143 to the NAT outbound as well, but that made it so that noone (reportedly) could make or receive calls at all (the customer was being screamed at by his guests). At this point I have disable the port 500, and switch the DNS from cloudflare to Quad9 wich seemed to have fixed the customers Tmobile phone. The only other thing I noticed was the “static port” option within the NAT outbound rules. some on forums say you need it enabled, while always talk about that option only allows a single device to use the tunnel at a time. I need advice badly as the customer wants me to put the USG Pro4 back in, because it worked just fine for WiFi calling.
Have you tried this?
https://www.reddit.com/r/PFSENSE/comments/jqmkiq/wifi_calling_fyi/ioka09j/
yes I did that along with changing the firewall to “Conservative”
I found that eliminating references to outbound NAT port 500 helped with WiFi calling. If you go to firewall rules, NAT, outbound NAT, change to hybrid mode, then deactivate (don’t delete) every rule that references destination port 500.
However, if you have an IPSEC VPN setup, I wouldn’t do this.
Yes I did eliminate the default NAT rules (port 500) as needed. no IPSec VPN on the network to worry about.
Did that resolve the issue??
Negative, as I stated in my post, I had already done that. about a month and half ago.
This might call for a packet capture to find more details.