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

    VOIP traffic dropped

    Scheduled Pinned Locked Moved Firewalling
    23 Posts 2 Posters 4.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.
    • awebsterA Offline
      awebster
      last edited by

      So what does the routing table look like on that platform?
      How do you enter a static route, and can you choose the interface on which it applies?  Maybe you need 2 routes, one for each interface?

      –A.

      1 Reply Last reply Reply Quote 0
      • T Offline
        timlie
        last edited by

        For 10.0.0.40 and 41 it uses our interface card (10.0.0.1) on ADMINISTRATIE as gateway.
        For 10.0.16.30 and 31 on KSTRAAT there is a static route on the gateway which sends traffic back to our 10.0.0.0/20 network.

        These routes are correct because pinging between eachother works.

        1 Reply Last reply Reply Quote 0
        • awebsterA Offline
          awebster
          last edited by

          @timlie:

          For 10.0.0.40 and 41 it uses our interface card (10.0.0.1) on ADMINISTRATIE as gateway.
          For 10.0.16.30 and 31 on KSTRAAT there is a static route on the gateway which sends traffic back to our 10.0.0.0/20 network.

          These routes are correct because pinging between eachother works.

          Right, but the ping is only using one of the two interfaces on the PBX, unless you can specify the source IP when initiating the ping.
          I suggest you use port mirroring on your switches to try and capture the traffic from each of the interfaces on the PBX to see if there actually is an attempt to send RTP traffic on either of these interfaces, and to what IP it is trying to send it, and more importantly to what L2 MAC address it is trying to deliver it.

          –A.

          1 Reply Last reply Reply Quote 0
          • T Offline
            timlie
            last edited by

            Ok, I think we should indeed try that in two weeks (we have a week holiday here next week). Thanks for your advice awebster, really appreciate this!

            1 Reply Last reply Reply Quote 0
            • T Offline
              timlie
              last edited by

              I was thinking, would it be possible that I have to use "Bypass firewall rules for traffic on the same interface"?

              Myself, I guess not because there is a static route on the other side but traffic always comes back on an interface on our pfsense…

              1 Reply Last reply Reply Quote 0
              • awebsterA Offline
                awebster
                last edited by

                Bypass firewall rules for traffic on the same interface only applies if you have a situation where traffic is bouncing off the interface (typically LAN side).
                IE: You have multiple different subnets that are reachable through a router on the LAN side, then you don't want the firewall inspecting traffic that is staying "inside" the network.

                Usually in this type of setup, you would have all hosts pointing to an internal router, whose default gateway is the pfSense LAN interface, but in some cases you might have some hosts that are pointing to pfSense LAN interface as default gateway and they need to reach other hosts via the router that is connected to pfSense LAN interface.

                –A.

                1 Reply Last reply Reply Quote 0
                • T Offline
                  timlie
                  last edited by

                  Ok, thanks. I'll get it.

                  That's not the case in our situation.

                  1 Reply Last reply Reply Quote 0
                  • T Offline
                    timlie
                    last edited by

                    Tomorrow I can test again on this case.
                    I received some extra information on these pbx's.

                    Apparantly the data signals are send on the first interface of the pbx (10.0.0.40 ; 10.0.16.30 ; 10.0.32.30) where the voice (RTP) is send over the second interface of the pbx (10.0.0.41 ; 10.0.16.31 ; 10.0.32.31).

                    The data signals are send correct between pbx's as seen in the capture. Voice is not.

                    Would it be possible that the synchronous RTP communication is blocked because there is no firewall state created for the second interfaces?

                    Thanks!

                    1 Reply Last reply Reply Quote 0
                    • awebsterA Offline
                      awebster
                      last edited by

                      @timlie, the state gets created when the first packet is sent, if the firewall allows it. and the firewall rules that you've shared earlier seem to indicate that everything open on the subnet, so RTP should be passing.

                      At this point everything is pointing to a routing problem on the PBX's second interface.
                      Here is one way to troubleshoot that:
                      On the pfSense that is working with PBX#1, if you run the following from the command prompt:
                        tcpdump -s 0 -n -i lan_interface host PBX#1_IP#1 or host PBX#1_IP#2 or host PBX#2_IP#1 or host PBX#2_IP#2
                      you should see communications taking place, including RTP if any.
                      You can optionally add -w filename.cap to the tcpdump command to write it to a file, and then open it up in wireshark.

                      If you see RTP traffic, then run the same command on the pfSense that is working with PBX#2 and check that the RTP traffic that PBX#1 is sending is going to PBX#2.

                      –A.

                      1 Reply Last reply Reply Quote 0
                      • T Offline
                        timlie
                        last edited by

                        Thanks awebster,

                        This capture showed us that the second interface was still using our old gateway because of an ARP table which this pbx didn't refresh.

                        Fixed now!
                        Thanks a lot!

                        1 Reply Last reply Reply Quote 0
                        • awebsterA Offline
                          awebster
                          last edited by

                          Glad that was easy to fix.
                          Please consider editing your original post to add [SOLVED] to the subject.

                          –A.

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