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.5k 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

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