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

    Accessing Sip server over OpenVPN

    Scheduled Pinned Locked Moved General pfSense Questions
    17 Posts 3 Posters 1.3k 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.
    • A
      ashima LAYER 8
      last edited by

      Scenario
      Site A : Pfsense 2.5.2 : Asterisk server
      Site B : Pfsense 2.6 : x-lite client
      Site A n Site B connected via OpenVPN

      Requirement:
      Use xlite softphone to access Asterisk Server

      Connectivity between Site A n Site B established. Can rdp to server in Site A.

      Using packet capture at Site B, observed Xlite client sending packets for registeration to Site B Pfsense at udp 5060.

      I want pfsense to reroute the packets received on port 5060 to firewall at site A which further route to Asterisk Server.

      How do I go about this ?

      Regards,
      Ashima

      N 1 Reply Last reply Reply Quote 0
      • N
        netblues @ashima
        last edited by

        @ashima

        Since you have a site to site vpn established, x-lite clinet should be able to reach asterisk server directly with its ip

        1 Reply Last reply Reply Quote 0
        • A
          ashima LAYER 8
          last edited by

          Yes you are right on that @netblues .

          I remember trying it earlier, but it was not connecting.
          But after getting reply from you, I realized that it's working

          Zapped myself.

          Anyway thanks a ton. May be your reply gave me confidence and it started working.

          1 Reply Last reply Reply Quote 2
          • A
            ashima LAYER 8
            last edited by ashima

            Facing another issue.

            The connection from xlite to asterisk server is established but the calls drop after 6 sec. Not experiencing any call drops when xlite is access Asterisk locally.

            Checking the forum suggests NATing issue.

            Need to clarify another point :

            At Site A : Main Pfsense Box (A1) with multiple ISps : Another Pfsense box (A2) : Asterisk Server
            Site B : Pfsense Box (B) : Xlite Client

            Site 2 Site connection is made between Box A1 of site A and Box B for Site B.
            Port forward of tcp/udp 5060 and 3478 done on Box A2 of site A

            Is this due to Port forward I am facing this issue.
            Any Pointers,

            N 1 Reply Last reply Reply Quote 0
            • N
              netblues @ashima
              last edited by

              @ashima A network diagram would help

              I guess you are firewalling asterisk and port forward internal traffic to it.

              SO how about rdp port ranges? typical 10.000 to 20.000 udp?

              A 1 Reply Last reply Reply Quote 0
              • A
                ashima LAYER 8
                last edited by

                @netblues

                Here is a rough diagram

                                      (172.16.9.3)    
  Pfsense Box A1  --- Pfsense Box A2 ----- Asterisk Server
     |
     |  OpenVPN Connect
     |
  Pfsense Box B  --- Xlite Client (192.168.7.5)

                Yes Asterisk is behind firewall Box A2. I am port forwarding port (tcp/udp) 5060 n 3478

                N 1 Reply Last reply Reply Quote 0
                • N
                  netblues @ashima
                  last edited by

                  @ashima No rdp??

                  A 1 Reply Last reply Reply Quote 0
                  • A
                    ashima LAYER 8 @netblues
                    last edited by

                    @netblues Yes I do rdp on port 3389 on Win server behind Box A2.

                    I have port forwarded 3389 on Box A2 to Win server

                    That is working fine. I am to able to rdp from site B to WIn Server at Site A

                    1 Reply Last reply Reply Quote 0
                    • A
                      ashima LAYER 8
                      last edited by

                      Here is a screenshot of Packet capture running on Pfsense box B

                      17:27:05.729114 IP 192.168.7.5.8400 > 172.16.9.3.3478: UDP, length 20
17:27:05.729167 IP 192.168.7.5.8401 > 172.16.9.3.3478: UDP, length 20
17:27:05.770056 IP 172.16.9.3 > 192.168.7.5: ICMP 172.16.9.3 udp port 3478 unreachable, length 56
17:27:05.770109 IP 172.16.9.3 > 192.168.7.5: ICMP 172.16.9.3 udp port 3478 unreachable, length 56
17:27:05.969331 IP 192.168.7.5.8400 > 172.16.9.3.3478: UDP, length 20
17:27:05.969359 IP 192.168.7.5.8401 > 172.16.9.3.3478: UDP, length 20
17:27:06.010368 IP 172.16.9.3 > 192.168.7.5: ICMP 172.16.9.3 udp port 3478 unreachable, length 56
17:27:06.010385 IP 172.16.9.3 > 192.168.7.5: ICMP 172.16.9.3 udp port 3478 unreachable, length 56
17:27:06.469273 IP 192.168.7.5.8400 > 172.16.9.3.3478: UDP, length 20
17:27:06.469303 IP 192.168.7.5.8401 > 172.16.9.3.3478: UDP, length 20
17:27:06.510091 IP 172.16.9.3 > 192.168.7.5: ICMP 172.16.9.3 udp port 3478 unreachable, length 56
17:27:06.510111 IP 172.16.9.3 > 192.168.7.5: ICMP 172.16.9.3 udp port 3478 unreachable, length 56
17:27:07.473528 IP 192.168.7.5.8400 > 172.16.9.3.3478: UDP, length 20
17:27:07.473562 IP 192.168.7.5.8401 > 172.16.9.3.3478: UDP, length 20
17:27:07.514075 IP 172.16.9.3 > 192.168.7.5: ICMP 172.16.9.3 udp port 3478 unreachable, length 56
17:27:08.473665 IP 192.168.7.5.8400 > 172.16.9.3.3478: UDP, length 20
17:27:08.473701 IP 192.168.7.5.8401 > 172.16.9.3.3478: UDP, length 20
17:27:08.514468 IP 172.16.9.3 > 192.168.7.5: ICMP 172.16.9.3 udp port 3478 unreachable, length 56
17:27:09.643209 IP 192.168.7.5.13124 > 172.16.9.3.5060: UDP, length 993
17:27:09.684850 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 553
17:27:09.685543 IP 192.168.7.5.13124 > 172.16.9.3.5060: UDP, length 319
17:27:09.788606 IP 192.168.7.5.13124 > 172.16.9.3.5060: UDP, length 1153
17:27:09.899588 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 504
17:27:10.377102 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 830
17:27:18.814965 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 602
17:27:18.919547 IP 192.168.7.5.13124 > 172.16.9.3.5060: UDP, length 546
17:27:18.919561 IP 192.168.7.5.13124 > 172.16.9.3.5060: UDP, length 4
17:27:22.514306 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 816
17:27:22.613545 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 816
17:27:22.813835 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 816
17:27:23.214383 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 816
17:27:24.013785 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 816
17:27:25.614259 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 816
17:27:28.813743 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 816
17:27:28.933847 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 577
17:27:29.033666 IP 172.16.9.3.5060 > 192.168.7.5.13124: UDP, length 577
17:27:29.036021 IP 192.168.7.5.13124 > 172.16.9.3.5060: UDP, length 387
17:27:29.036053 IP 192.168.7.5.13124 > 172.16.9.3.5060: UDP, length 387
                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        When you test 'locally' is the test client also behind firewall A2?

                        SIP hates NAT but it should be configurable to work. The most common problem is the PBX handing out it's local IP to external clients to connect back to that they cannot reach.

                        It would be much better to remove NAT here and make it all routed if you can.

                        And/or have the remote client connect to an OpenVPN server on A2 directly.

                        Steve

                        1 Reply Last reply Reply Quote 0
                        • A
                          ashima LAYER 8 @netblues
                          last edited by

                          @netblues Sorry I guess you mean rtp ports

                          Yes I have forwarded rtp ports : 10000:20000

                          1 Reply Last reply Reply Quote 0
                          • A
                            ashima LAYER 8
                            last edited by

                            Thank you @stephenw10 for replying.

                            Yes, the test was done locally behind the firewall A2.

                            I made the VPN connection to Firewall A2 from Firewall B and things started working.

                            I wish I could make it working using VPN firewall A1 as I have all my branches getting connected to firewall A1 for other services.

                            What settings do I need to do in Firewall A2 n B to make it work. I was reading following :

                            https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-phones.html
                            https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-pbx.html

                            Also bit confuse about settings in asterisk server. Adding another local network in sip.conf. (Not sure how to do that)

                            Any pointers on this.

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

                              I would convert Firewall A2 to be routed only (no NAT) if you can.

                              Does the call initially connect with audio both ways?

                              1 Reply Last reply Reply Quote 0
                              • A
                                ashima LAYER 8
                                last edited by

                                @stephenw10 As suggested I am connecting to A2 (No NAt).

                                Audio both ways ... I didn't really understand that.

                                We need to do make outbound calls and receive inbound calls. Need to do only call recordings.

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

                                  You have converted Firewall A2 to route only? Or you switched the VPN to connect to A2?

                                  So you are able to make and receive calls and you get audio in both directions but the calls are dropped after a few seconds? In both directions?

                                  That does sound like route asymmetry but it's hard to see where that could be happening.

                                  Try running a packet capture for the SIP traffic and see if one end is disconnecting the call intentionally.

                                  Steve

                                  1 Reply Last reply Reply Quote 0
                                  • A
                                    ashima LAYER 8
                                    last edited by

                                    @stephenw10

                                    Yes I have connected the vpn to A2. Every thing is working fine. No call drops. Audio is working in either direction.

                                    Thank you for all the support.

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

                                      Ok, well you likely could also correct it by converting A2 to routing only and leaving the VPN on A1 which might be easier for you with all the other clients.

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