Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Tip - I solved my WiFi Calling issues

    Scheduled Pinned Locked Moved General pfSense Questions
    12 Posts 10 Posters 7.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      tomk
      last edited by

      I finally remembered that I meant to share this months ago when I discovered it, so here I am ...

      I'll be succinct:

      • I have all iPhones in the house, and WiFi calling was sporadic on all of them. It might work for a while, or only a few minutes, or never manage to negotiate the Wi-Fi calling connection at all
      • Two iPhones could never be on WiFi Calling at the same time
      • Providers are Rogers (x2) and Fido (x1)
      • pfSense 2.4 series, bone stock rules

      The problem was the auto-generated ISAKMP rules. I turned them off:
      Screen Shot 2020-04-20 at 10.52.40 AM.png

      Now WiFi Calling is perfect on any iOS device on my home network.

      However, from the docs (https://docs.netgate.com/pfsense/en/latest/nat/static-port.html) ...
      Automatic Outbound NAT rules on the pfSense firewall will retain the source port for UDP 500 (ISAKMP for IPsec VPN traffic) by default because this traffic will almost always be broken by rewriting the source port.

      So, your mileage may differ if you use IPsec for other than WiFi Calling. Behaviour may differ between providers, too.

      Cheers!

      JKnottJ 1 Reply Last reply Reply Quote 1
      • JKnottJ
        JKnott @tomk
        last edited by

        @tomk said in Tip - I solved my WiFi Calling issues:

        I have all iPhones in the house

        That's the problem. 😉

        PfSense running on Qotom mini PC
        i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
        UniFi AC-Lite access point

        I haven't lost my mind. It's around here...somewhere...

        1 Reply Last reply Reply Quote 2
        • N
          nheath
          last edited by

          I just started having wifi calling issues after upgrading to 2.4.5. I deleted the default isakmp rules a long time ago so I appear to be having a different issue. Are there any good resources on wifi calling that you know of to help me troubleshoot this issue?

          JKnottJ Z 2 Replies Last reply Reply Quote 0
          • JKnottJ
            JKnott @nheath
            last edited by

            @nicheath

            WiFi calling is VoIP encapsulated in IPSec, encapulated in UDP. So, your issues will be with passing IPSec/UDP.

            PfSense running on Qotom mini PC
            i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
            UniFi AC-Lite access point

            I haven't lost my mind. It's around here...somewhere...

            1 Reply Last reply Reply Quote 1
            • Z
              zaogrnutess Banned @nheath
              last edited by stephenw10

              [Spam was here]

              JKnottJ 1 Reply Last reply Reply Quote 0
              • JKnottJ
                JKnott @zaogrnutess
                last edited by

                @zaogrnutess

                FWIW, I am also on Rogers and haven't noticed any problems. However, I have only one Android phone.

                PfSense running on Qotom mini PC
                i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                UniFi AC-Lite access point

                I haven't lost my mind. It's around here...somewhere...

                1 Reply Last reply Reply Quote 0
                • G
                  Glorialove Banned
                  last edited by

                  This post is deleted!
                  1 Reply Last reply Reply Quote 0
                  • M
                    Michaelslo Banned
                    last edited by

                    This post is deleted!
                    1 Reply Last reply Reply Quote 0
                    • M
                      mantis0711
                      last edited by mantis0711

                      A little bit of thread necromancy here.

                      I have had the same issue -- intermittent problems with my Verizon Wi-Fi calling behind PfSense. I had the default auto generated rules active.

                      When I disable the ISAKMP rule, the problem resolves. I can consistently repro this. Rebooting my iPhone is the most reliable way to see whether it's currently working, as it will attempt to setup the tunnel as soon as you unlock the phone and it jumps on WiFi.

                      This doesn't make a lot of sense to me. The ISAKMP rule is static mapping the port, and if it's disabled, that port is then being rewritten/randomized. Why is this making a difference? Why does this work? I'm on 2.4.5-RELEASE-p1.

                      Edit: I also just tested setting a catch-all static NAT rule at the top of the list. Simply using static NAT does not break Wi-Fi calling. In fact it is still broken merely by toggling on the ISAKMP rule which is several rules beneath it in the list. Really weird.

                      I cannot quite put my finger on when Wifi calling broke for me but it does seem to align with upgrading to 2.4.5 for me.

                      Ultimately I don't think my network really needs PF to rewrite my source ports, and I already have had to write outbound NAT rules to deal with various video games (old and new) that use UDP hole punching methods. My fix for now is just going full manual and using static port.

                      1 Reply Last reply Reply Quote 0
                      • T
                        tman222
                        last edited by

                        Thought I would share a few of my own thoughts and experiences enabling WiFi calling behind pfSense based primarily on using Verizon as the cellular provider:

                        1. Apple devices (e.g. iPhones) have worked well for me without any modification need to pfSense settings. What I have noticed, however, is that iPhones may switch back to the cellular network if the signal improves even through WiFi calling is enabled. One way around this (and to essentially force WiFi calling) is to put the phone in airplane mode, effectively disabling the cellular component. Calls & text messages still work just fine. On a related note, this behavior doesn't appear to be unique to Verizon. I have also seen this on a device that was using AT&T as the cellular provider. Again, enabling airplane mode helped to persist WiFi calling.

                        2. For Android devices with WiFi calling enabled I received word from a family member that calls were not connecting and there were also problems with texting. The solution for me was to change "Firewall Optimization Options" to "Conservative" under System > Advanced > Firewall & NAT. There have been no more issues since making this adjustment to the settings. More details here in this thread: https://forum.netgate.com/topic/155113/wifi-calling-issue/

                        Hope this helps.

                        1 Reply Last reply Reply Quote 1
                        • E
                          Emily Banned
                          last edited by

                          This post is deleted!
                          1 Reply Last reply Reply Quote 0
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            Locking this, it's just attracting spam at this point.

                            1 Reply Last reply Reply Quote 0
                            • S SteveITS referenced this topic on
                            • J JT40 referenced this topic on
                            • J JT40 referenced this topic on
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.