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

    VOIP thru IpSec VPN problems

    Scheduled Pinned Locked Moved General pfSense Questions
    17 Posts 3 Posters 3.8k 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.
    • DerelictD
      Derelict LAYER 8 Netgate
      last edited by

      It is almost impossible to diagnose something like this wilout real information and screen captures, packet captures, etc.

      You can start by describing, in detail, where the:

      Phones are
      The PBX is
      The SIP trunks, of any, are.

      Preferably in relation to the PfSense node(s).

      It sounds like you broke the connection to the SIP provider and it has nothing to do with IPsec. The all need different things. If your SIP provider has any guidance for configuring a firewall that does NAT, that would also be helpful information.

      But ALL of those settings such as high-latency and no scrubbing back to the default. They are meaningless. You probably need additional port forwards, firewall rules, and maybe some static NAT ports done properly.

      Look for blocked connections from the SIP provider when you make a call that fails.

      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 0
      • R
        rbrtpf
        last edited by

        First, remember that everything worked until I setup my SIP provider as an alias to insert the 'alias' into the firewall rules to accept traffic ONLY from SIP provider. Once this was in place (to stop the blacklist IP address attacks) RTP stopped working for the extensions at home location "B". I can still dial a number from any extension at location "B" and receive calls from (my cellphone) to any extension at location "B". However, no voice (RTP) and all calls (to or from) time out after 31 seconds due to lack of voice connection.

        I have not broken my connection to my SIP Provider as location "A" (Office) calls are still working and do not time out.

        The IPsec tunnel is simple shared key type.

        All extensions connect to 192.168.16.222 the FreePBX box.

        Attached is a drawing (crude) and a packet capture (level of detail set at "medium") from the PfSense at "location A (office)" of the Yealink T23G extension (ip address) 192.168.242.170 at "location B".

        Your help is greatly appreciated. Thank you in advance.

        FreePBX-draw-layout.png
        FreePBX-draw-layout.png_thumb
        packetcapture-ext210_2017-09-18.txt

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

          Please just download and attach the pcap so wireshark can do the heavy lifting. Thanks.

          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 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            First, remember that everything worked until I setup my SIP provider as an alias to insert the 'alias' into the firewall rules to accept traffic ONLY from SIP provider. Once this was in place (to stop the blacklist IP address attacks) RTP stopped working for the extensions at home location "B".

            There is no way a rule on WAN at location A can impact SIP over IPsec between A & B. You must be blocking something now that needs to be passed to/from the SIP provider.  Perhaps site A and B were using the actual public IP address from B to A for RTP and not IPsec at all? Add the WAN address of Site B to the alias and see what happens.

            Check your firewall logs.

            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 0
            • R
              rbrtpf
              last edited by

              Thank you for your suggestion.

              Sorry, please notice that it says "newbie" below my login so, simplest of questions.

              You said "Add the WAN address of Site B to the alias and see what happens." By that you mean to add the Site B WAN Address as an alias of the site A firewall rules?

              But, that confuses me. All other computers, I have no problem ssh into, etc. through the VPN tunnel.

              I am correct in that site B should be communicating back to the FreePBX box through the IPsec tunnel NOT site B connecting to my SIP provider over the internet?

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

                No. Add it to the alias you are using to limit connections from the SIP provider. To also pass those connections from site B (if they exist).

                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 0
                • R
                  rbrtpf
                  last edited by

                  Your suggestion has solved my problem. Adding the ip address of location "B" to the location "A" alias gave permission for a voice connection.

                  I believe, as you have suggested, that it has to do with the extension responding to FreePBX with location "B" wan address in the RTP requests strings. As PfSense would allow ONLY my SIP provider then PfSense was rejecting the extensions RTP request.

                  Thank you. Your patience and help are greatly appreciated.

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

                    Glad that worked.

                    There is probably something in the PBX that will treat the site B subnet as an inside subnet so it gets the PBX's inside address in the SIP/RTP requests so that site connects over the VPN instead of over the WAN.

                    It would probably be a good idea to fix that.

                    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 0
                    • A
                      awair
                      last edited by

                      I'm using an older version of FreePBX with a similar setup.

                      Have a look at sip_nat.conf, mine is like this:

                      localnet=192.168.1.0/255.255.255.0     ;SiteA
                      localnet=192.168.2.0/255.255.255.0      ;SiteB
                      nat=yes
                      externip=1.2.3.4
                      fromdomain=example.com 
                      

                      You can also set similar in Settings/Asterisk SIP Settings (- my system highlights an Error because the contents are different: I've chosen to leave this, while it works, until I change the network again).

                      ![Screenshot - MBA11 2017-09-22 at 23.14.53.jpg](/public/imported_attachments/1/Screenshot - MBA11 2017-09-22 at 23.14.53.jpg)
                      ![Screenshot - MBA11 2017-09-22 at 23.14.53.jpg_thumb](/public/imported_attachments/1/Screenshot - MBA11 2017-09-22 at 23.14.53.jpg_thumb)

                      2.4.3 (amd64)
                      and given up on the SG-1000

                      1 Reply Last reply Reply Quote 0
                      • R
                        rbrtpf
                        last edited by

                        Yes, thank you, I am aware of this FreePBX option.

                        My issue was NOT with FreePBX connecting ONLY with my SIP provider it was the extensions located through IPSec VPN that could not properly connect.

                        Every situation is unique, mine more unique than many, I suspect but, the issue was PfSense (doing it's job) allowing ONLY my SIP provider to connect and NOT allowing my extensions through VPN to connect. Once the VPN alias I setup was added then, my extensions connected and worked properly.

                        I appreciate your suggestion.

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

                          I believe you are still missing the point. But they're your phone conversations going over the clear internet instead of the VPN so no skin off my nose.

                          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 0
                          • R
                            rbrtpf
                            last edited by

                            I'll see what FreePBX forum thinks about this.

                            But, it appears to me that this is a PfSense issue not allowing connection. I think your right that the ipaddress is being changed (probably by FreePBX) and therefore PfSense will block but, I am still working this out.

                            By your comment, I just now realize that you are right the conversions could be connecting over the net.

                            We'll see.

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

                              Look.

                              Your WAN rules have ZERO effect on connections over IPsec.

                              The problem is your other site is connecting RTP over the internet instead of IPsec. That is because your PBX is giving them the public address to connect to instead of the private address that would be interesting to IPsec.

                              pfSense is just doing what it is told to do.

                              It's not pfSense. It is your broken PBX configuration.

                              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 0
                              • R
                                rbrtpf
                                last edited by

                                I believe you. Currently working with FreePBX forum to resolve this.

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