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

    SIP-Calls over LTE drop after exactly 32 seconds (OpenVPN) - WiFi is fine

    Scheduled Pinned Locked Moved General pfSense Questions
    19 Posts 7 Posters 1.9k 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
      Tenou
      last edited by

      It's already set to conservative. I have to add that I mistakenly thought, what works in one Wifi also does in others. This is not limited to LTE, in other WiFi-Networks the same problem occurs.

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        Sounds like you have a one-way traffic problem. Probably need to set the correct external IP address in FreePBX.

        It's in the NAT settings in your SIP settings.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

          Does the VPN drop or just the call over it?

          About the only thing that could potentially be different there for the SIP connection would be the tunnel MTU.

          Steve

          T 1 Reply Last reply Reply Quote 0
          • T
            Tenou @Derelict
            last edited by Tenou

            @Derelict Don't think so. Wouldn't that mean one party could not hear the other? Besides that, if eg. the WAN IP would be wrong, I wouldn't be able to take a phone call using local extensions.

            1 Reply Last reply Reply Quote 0
            • T
              Tenou @stephenw10
              last edited by Tenou

              @stephenw10 The VPN itself is fine. It's the call dropping. I'll look into the MTU settings, tho it's pretty unlikely they're the cause, I believe.
              These 32 seconds are pretty common for SIP ALG or NAT issues, but I couldn't find a misconfig there either.

              I have a second VPN used for remote hard phones, I'll go compare them later.

              1 Reply Last reply Reply Quote 0
              • PippinP
                Pippin
                last edited by

                A guess, try Do not fragment and/or Disable scrub.

                I gloomily came to the ironic conclusion that if you take a highly intelligent person and give them the best possible, elite education, then you will most likely wind up with an academic who is completely impervious to reality.
                Halton Arp

                T 1 Reply Last reply Reply Quote 0
                • T
                  Tenou @Pippin
                  last edited by

                  @Pippin Tried that, still no difference..

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

                    Traffic in both cases goes over the tunnel both SIP and RTP as I understand it? That's the only path it has to the PBX.

                    The SIP traffic has no way to know or care about the route the tunnel is using other than the MTU. I can't see what else it could be really.

                    If the tunnel does not fail the SIP is using exactly the same route, NAT, ALG etc.

                    Steve

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

                      I just noticed, this only happens for outbound calls from the softphone. Inbound calls are fine. MTU values are fine.

                      1 Reply Last reply Reply Quote 0
                      • DerelictD
                        Derelict LAYER 8 Netgate
                        last edited by Derelict

                        A 30 second state kill is an indicator of asymmetric routing.

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

                          Are you not using OpenVPN when connecting over wifi?
                          That would imply it's local wifi in which case many things will be different.

                          Steve

                          T 1 Reply Last reply Reply Quote 0
                          • T
                            Tenou @stephenw10
                            last edited by Tenou

                            @stephenw10 I'm using OpenVPN all the time. At no point is the phone directly connected to the local network of the PBX.
                            Besides that: I tried some stuff out today and it seems to be indipendent of LTE/WiFi. When I'm connected to my home WiFi, it works. When connected to LTE it's dropping after 32 seconds, same for my WiFi at work. So we'll have to drop the thought that it's only LTE, it's depending on the network.

                            I just read asterisk logs and took a detailed look at the IPs. My LTE-ISP seems to use a NAT-pool and then assign local IPs to the phones connected to the network. So effectively he's using one WAN IP and is "splitting" it up for multiple end users. But since it's NAT, I'd guess that's where the problem is. I'll get in touch with my ISP and we'll see how it goes.

                            Regarding my WiFi at work, I'll take a look at how it's configured tomorrow and eventually try different WiFis, like McDonalds, Shopping Center etc.

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

                              About the only thing that could potentially be different there for the SIP connection would be the tunnel MTU.

                              A guess, try Do not fragment and/or Disable scrub

                              VoIP packets tend to be small, so neither MTU nor fragmentation would be an issue. For example, a G.711 codec (toll quality), produces 64 Kb/s or 8 KB/s. Packets typically contain 20 mS of audio or 50 packets per second. That means each packet will contain 1280 bits or 160 bytes, plus overhead. That's far smaller than the smallest MTU you're likely to find.

                              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
                              • stephenw10S
                                stephenw10 Netgate Administrator
                                last edited by

                                Is your home wifi where the pfSense appliance is? Is the pfSense appliance just used as a VPN server here?

                                The 30s time period and the fact that VoIP traffic is usually all small sure looks more like route asymmtery somewhere.

                                Steve

                                T 1 Reply Last reply Reply Quote 0
                                • T
                                  Tenou @stephenw10
                                  last edited by

                                  @stephenw10 No, my PBX is at another location. And even if it was, it would still be connected via VPN because of the way my network is set up :D I have a "Main"-Location, where all the servermagic happens and my home, which is a completly different story. Sorry for not clarifying!

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

                                    Hmm, well if the SIP traffic is always over the VPN it's hard to see how the routing could vary.

                                    But I would still be checking for any blocked traffic to/from the phone tunnel IP or to/from the PBX anywhere.
                                    It really looks like a state expiring and that is almost always asymmetry.

                                    Steve

                                    1 Reply Last reply Reply Quote 0
                                    • A
                                      AndrewZ
                                      last edited by AndrewZ

                                      @Tenou said in SIP-Calls over LTE drop after exactly 32 seconds (OpenVPN) - WiFi is fine:

                                      The VPN-Subnet is configured as “local trusted”

                                      Not sure what you mean with 'trusted', but your VPN subnet should be added to a list of local networks in Asterisk. Then check your SIP signalling on Asterisk side.
                                      I see no signs that pfSense has anything to do with your problem. Please read this and follow the link there.

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