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.
    • 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.