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

    Whatsapp call reconnecting after 5 sec. Do not allow calls.

    Scheduled Pinned Locked Moved General pfSense Questions
    12 Posts 2 Posters 1.4k 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.
    • F
      fredis
      last edited by

      I have a SG-2100 pfsense+, all was working fine. however, a week ago, the whatsapp call is not working, the call connects for 5 seconds and it goes to reconnecting state and after few seconds, it drops the call.

      No configuration changes were done. firewall is 'allow all'. It was working before. The configuration is simple, WAN (dhcp), LAN (default network), firewall 'allow all'.

      I tried reseting to fabric default, but same behavior, when I bypass the SG-2100, the whatsapp calls are working fine. The issue is when the traffic traverses the pfsense+.

      Version 23.09.1-RELEASE

      Any ideas?.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        When it fails do you see blocked traffic in the firewall log?

        Anything in the system log?

        Do you have any packages installed?

        Steve

        F 1 Reply Last reply Reply Quote 0
        • F
          fredis @stephenw10
          last edited by

          @stephenw10
          Thanks for your reply, there are no logs for the local IP.

          Firewall LAN.jpg

          Firewall WAN.jpg

          Firewall logs.jpg

          Diagnostic states: local IP 172.16.1.24 to whatsapp servers.

          LAN tcp 172.16.1.24:51616 -> 17.57.144.39:5223 ESTABLISHED:ESTABLISHED 114 / 73 73 KiB / 10 KiB
          LAN tcp 172.16.1.24:52618 -> 31.13.88.62:3478 TIME_WAIT:TIME_WAIT 18 / 13 1 KiB / 1 KiB
          LAN tcp 172.16.1.24:52619 -> 31.13.70.48:3478 TIME_WAIT:TIME_WAIT 18 / 12 1 KiB / 1 KiB
          LAN tcp 172.16.1.24:52621 -> 157.240.6.51:3478 TIME_WAIT:TIME_WAIT 18 / 17 1 KiB / 2 KiB
          LAN tcp 172.16.1.24:52623 -> 31.13.66.53:3478 ESTABLISHED:CLOSING 17 / 12 1 KiB / 1 KiB
          LAN tcp 172.16.1.24:52624 -> 31.13.65.48:3478 ESTABLISHED:CLOSING 17 / 12 1 KiB / 1 KiB
          LAN tcp 172.16.1.24:52625 -> 31.13.70.48:3478 ESTABLISHED:CLOSING 15 / 11 1 KiB / 1 KiB
          LAN tcp 172.16.1.24:52626 -> 157.240.6.54:5222 ESTABLISHED:ESTABLISHED 112 / 128 10 KiB / 31 KiB
          LAN udp 172.16.1.24:5353 -> 224.0.0.251:5353 NO_TRAFFIC:SINGLE 12 / 0 1 KiB / 0 B
          LAN udp 172.16.1.24:59956 -> 163.70.152.62:3478 MULTIPLE:MULTIPLE 17 / 16 5 KiB / 5 KiB
          LAN udp 172.16.1.24:59956 -> 157.240.229.62:3478 MULTIPLE:MULTIPLE 8 / 8 3 KiB / 3 KiB
          LAN udp 172.16.1.24:59956 -> 31.13.65.48:3478 MULTIPLE:MULTIPLE 8 / 7 3 KiB / 3 KiB
          LAN tcp 172.16.1.24:51622 -> 17.253.13.203:443 FIN_WAIT_2:FIN_WAIT_2 12 / 13 2 KiB / 5 KiB
          LAN udp 172.16.1.24:49422 -> 157.240.6.51:3478 MULTIPLE:MULTIPLE 224 / 223 50 KiB / 55 KiB
          LAN udp 172.16.1.24:49422 -> 31.13.67.51:3478 NO_TRAFFIC:SINGLE 14 / 0 5 KiB / 0 B
          LAN udp 172.16.1.24:49422 -> 157.240.229.62:3478 MULTIPLE:MULTIPLE 8 / 7 3 KiB / 3 KiB
          LAN udp 172.16.1.24:49422 -> 31.13.65.48:3478 MULTIPLE:MULTIPLE 8 / 7 3 KiB / 3 KiB
          LAN udp 172.16.1.24:49422 -> 157.240.11.51:3478 NO_TRAFFIC:SINGLE 14 / 0 5 KiB / 0 B
          LAN udp 172.16.1.24:49422 -> 200.85.83.74:16975 NO_TRAFFIC:SINGLE 20 / 0 1 KiB / 0 B
          LAN tcp 172.16.1.24:52632 -> 157.240.6.51:3478 ESTABLISHED:CLOSING 12 / 12 834 B / 1 KiB
          LAN tcp 172.16.1.24:52633 -> 31.13.67.51:3478 CLOSED:SYN_SENT 2 / 0 128 B / 0 B
          LAN tcp 172.16.1.24:52634 -> 157.240.229.62:3478 ESTABLISHED:CLOSING 10 / 10 686 B / 934 B
          LAN tcp 172.16.1.24:52635 -> 31.13.65.48:3478 ESTABLISHED:CLOSING 9 / 9 612 B / 832 B
          LAN tcp 172.16.1.24:52636 -> 157.240.11.51:3478 CLOSED:SYN_SENT 2 / 0 128 B / 0 B

          LAN tcp 172.16.1.24:51616 -> 17.57.144.39:5223 ESTABLISHED:ESTABLISHED 112 / 71 73 KiB / 9 KiB
          LAN tcp 172.16.1.24:52618 -> 31.13.88.62:3478 TIME_WAIT:TIME_WAIT 18 / 13 1 KiB / 1 KiB
          LAN tcp 172.16.1.24:52619 -> 31.13.70.48:3478 ESTABLISHED:CLOSING 17 / 12 1 KiB / 1 KiB
          LAN tcp 172.16.1.24:52621 -> 157.240.6.51:3478 TIME_WAIT:TIME_WAIT 18 / 17 1 KiB / 2 KiB
          LAN tcp 172.16.1.24:52623 -> 31.13.66.53:3478 ESTABLISHED:CLOSING 15 / 12 1 KiB / 1 KiB
          LAN tcp 172.16.1.24:52624 -> 31.13.65.48:3478 ESTABLISHED:CLOSING 15 / 12 1 KiB / 1 KiB
          LAN tcp 172.16.1.24:52625 -> 31.13.70.48:3478 ESTABLISHED:CLOSING 13 / 11 908 B / 1 KiB
          LAN tcp 172.16.1.24:52626 -> 157.240.6.54:5222 ESTABLISHED:ESTABLISHED 102 / 118 9 KiB / 30 KiB
          LAN udp 172.16.1.24:5353 -> 224.0.0.251:5353 NO_TRAFFIC:SINGLE 8 / 0 1 KiB / 0 B
          LAN udp 172.16.1.24:59956 -> 163.70.152.62:3478 MULTIPLE:MULTIPLE 17 / 16 5 KiB / 5 KiB
          LAN udp 172.16.1.24:59956 -> 157.240.14.51:3478 NO_TRAFFIC:SINGLE 14 / 0 5 KiB / 0 B
          LAN udp 172.16.1.24:59956 -> 157.240.229.62:3478 MULTIPLE:MULTIPLE 8 / 8 3 KiB / 3 KiB
          LAN udp 172.16.1.24:59956 -> 157.240.11.51:3478 NO_TRAFFIC:SINGLE 14 / 0 5 KiB / 0 B
          LAN udp 172.16.1.24:59956 -> 31.13.65.48:3478 MULTIPLE:MULTIPLE 8 / 7 3 KiB / 3 KiB
          LAN udp 172.16.1.24:60389 -> 172.16.1.1:53 SINGLE:MULTIPLE 1 / 1 86 B / 207 B
          LAN udp 172.16.1.24:63569 -> 172.16.1.1:53 SINGLE:MULTIPLE 1 / 1 86 B / 179 B
          LAN tcp 172.16.1.24:51622 -> 17.253.13.203:443 ESTABLISHED:ESTABLISHED 9 / 11 2 KiB / 5 KiB
          LAN udp 172.16.1.24:64476 -> 172.16.1.1:53 SINGLE:MULTIPLE 1 / 1 67 B / 127 B
          LAN tcp 172.16.1.24:52627 -> 163.70.152.62:3478 CLOSED:SYN_SENT 2 / 0 128 B / 0 B
          LAN tcp 172.16.1.24:52628 -> 157.240.14.51:3478 CLOSED:SYN_SENT 2 / 0 128 B / 0 B
          LAN tcp 172.16.1.24:52629 -> 157.240.229.62:3478 CLOSED:SYN_SENT 2 / 0 128 B / 0 B
          LAN tcp 172.16.1.24:52630 -> 157.240.11.51:3478 CLOSED:SYN_SENT 2 / 0 128 B / 0 B
          LAN tcp 172.16.1.24:52631 -> 31.13.65.48:3478 CLOSED:SYN_SENT 2 / 0 128 B / 0 B
          LAN udp 172.16.1.24:49422 -> 157.240.6.51:3478 MULTIPLE:MULTIPLE 32 / 31 7 KiB / 7 KiB
          LAN udp 172.16.1.24:49422 -> 31.13.67.51:3478 NO_TRAFFIC:SINGLE 4 / 0 2 KiB / 0 B
          LAN udp 172.16.1.24:49422 -> 157.240.229.62:3478 SINGLE:MULTIPLE 2 / 1 800 B / 96 B
          LAN udp 172.16.1.24:49422 -> 31.13.65.48:3478 SINGLE:MULTIPLE 2 / 1 800 B / 96 B
          LAN udp 172.16.1.24:49422 -> 157.240.11.51:3478 NO_TRAFFIC:SINGLE 4 / 0 2 KiB / 0 B
          LAN udp 172.16.1.24:49422 -> 200.85.83.74:16975 NO_TRAFFIC:SINGLE 4 / 0 288 B / 0 B

          I reset to factory default, no additional packages installed.

          BR,
          Fredi

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Hmm, you have allow all rules (wide open) on the WAN? Is it behind some other firewall/router? Otherwise you definitely don't want rules like that on WAN!

            I assume you also see states, with NAT, on the WAN interface?

            F 1 Reply Last reply Reply Quote 0
            • F
              fredis @stephenw10
              last edited by

              @stephenw10
              I configured 'allow all' only for troubleshoot purpose, however the issue persists, it means, the firewall rules are not blocking the traffic.

              On WAN side, I see the state:

              WAN: 192.168.100.6
              LAN: 172.16.1.24

              WAN tcp 192.168.100.6:62740 (172.16.1.24:51624) -> 17.57.144.38:5223 ESTABLISHED:ESTABLISHED 43 / 31 29 KiB / 6 KiB
              WAN tcp 192.168.100.6:54217 (172.16.1.24:51626) -> 181.39.103.80:443 TIME_WAIT:TIME_WAIT 20 / 23 5 KiB / 8 KiB
              WAN tcp 192.168.100.6:58723 (172.16.1.24:51627) -> 181.39.103.91:443 TIME_WAIT:TIME_WAIT 20 / 22 4 KiB / 9 KiB
              WAN tcp 192.168.100.6:28394 (172.16.1.24:51628) -> 104.110.176.24:443 TIME_WAIT:TIME_WAIT 41 / 49 5 KiB / 43 KiB
              WAN tcp 192.168.100.6:44506 (172.16.1.24:51629) -> 17.248.201.74:443 TIME_WAIT:TIME_WAIT 12 / 14 3 KiB / 7 KiB
              WAN tcp 192.168.100.6:9320 (172.16.1.24:52638) -> 157.240.6.54:5222 ESTABLISHED:ESTABLISHED 71 / 79 6 KiB / 13 KiB
              WAN tcp 192.168.100.6:42016 (172.16.1.24:51630) -> 17.253.13.209:443 ESTABLISHED:ESTABLISHED 9 / 10 2 KiB / 5 KiB
              WAN udp 192.168.100.6:35578 (172.16.1.24:61419) -> 181.39.187.163:3478 SINGLE:NO_TRAFFIC 14 / 0 5 KiB / 0 B
              WAN udp 192.168.100.6:5517 (172.16.1.24:61419) -> 163.70.152.62:3478 MULTIPLE:MULTIPLE 187 / 187 43 KiB / 47 KiB
              WAN udp 192.168.100.6:29188 (172.16.1.24:61419) -> 31.13.67.51:3478 SINGLE:NO_TRAFFIC 14 / 0 5 KiB / 0 B
              WAN udp 192.168.100.6:15498 (172.16.1.24:61419) -> 31.13.66.53:3478 MULTIPLE:MULTIPLE 6 / 5 2 KiB / 2 KiB
              WAN udp 192.168.100.6:10140 (172.16.1.24:61419) -> 157.240.241.62:3478 MULTIPLE:MULTIPLE 6 / 5 2 KiB / 2 KiB

              ISP router is in upstream but it has not a firewall applied.

              BR,
              Fredi

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by stephenw10

                Hmm, but it is double NATing all the traffic.

                Are you able to test with a public IP on the pfSense WAN?

                I'd expect it to still work fine through double NAT though.

                F 1 Reply Last reply Reply Quote 0
                • F
                  fredis @stephenw10
                  last edited by

                  @stephenw10
                  Is not possible for me to test with a public IP address on WAN interface.

                  It was working fine.
                  Messenger calls and other apps are working fine.
                  When I try Whatsapp videocall, the video keeps online while it trying to reconnect the voice, few seconds, the videocall drops.

                  Fredi

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    Any errors shown in Status > Interfaces?

                    MTU mismatch somewhere?

                    If nothing changed in pfSense did anything change in the ISP router?

                    F 1 Reply Last reply Reply Quote 0
                    • F
                      fredis @stephenw10
                      last edited by

                      @stephenw10

                      There are not errors on interfaces.

                      Interface Statistics.jpg

                      MTU: default values: 1500 bytes.

                      [23.09.1-RELEASE][admin@pfSense.home.arpa]/root: ifconfig | grep mtu
                      mvneta0: flags=1008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
                      mvneta1: flags=1008a43<UP,BROADCAST,RUNNING,ALLMULTI,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
                      enc0: flags=0 metric 0 mtu 1536
                      lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
                      pflog0: flags=100<PROMISC> metric 0 mtu 33152
                      pfsync0: flags=0 metric 0 mtu 1500
                      mvneta1.30: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
                      mvneta1.11: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
                      mvneta1.12: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
                      mvneta1.13: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
                      mvneta1.14: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
                      mvneta1.99: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
                      mvneta1.16: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500

                      ISP discarded some issues.

                      When bypass the SG-2100, the issue is resolved.

                      All tests point to SG issue, but I don't sure what is the RCA of the issue.

                      Fredi

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        Is the behaviour the same on any of those VLANs?

                        F 1 Reply Last reply Reply Quote 0
                        • F
                          fredis @stephenw10
                          last edited by

                          @stephenw10
                          Yes, same behavior on different Vlans.
                          I tested Android to Android, IOS to Android and IOS to IOS. Same issue.

                          Fredi

                          1 Reply Last reply Reply Quote 1
                          • stephenw10S
                            stephenw10 Netgate Administrator
                            last edited by

                            Something must have changed. Maybe the app version?

                            Can you test this behind some other device running pfSense CE to rule out something hardware specific?

                            If this was breaking whatsapp calls for everyone there would be many, many threads!

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.