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

    TCP:SA Packets Blocked when Sending VoIP Traffic to alternate GW on Both Ends

    Scheduled Pinned Locked Moved Firewalling
    16 Posts 2 Posters 2.0k 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.
    • S Offline
      Spiffster
      last edited by

      No floating rules in place. Attached rules for LAN on each fw. Thanks!

      fw_Rules.png
      fw_Rules.png_thumb

      1 Reply Last reply Reply Quote 0
      • S Offline
        Spiffster
        last edited by

        What I see when I boot up the phones at remote office is they grab DHCP info from the local DHCP server, that will point them to grab their configs from the Avaya IPO server, they send a TCP:S to the server and never get the TCP:SA response because its blocked. Cant make any sense of it.

        1 Reply Last reply Reply Quote 0
        • johnpozJ Offline
          johnpoz LAYER 8 Global Moderator
          last edited by

          I don't see any hits on that rule for 192.168.5.12 as source.. Is that 192.168.5 a downstream network?  Maybe the device has a different gateway set so it would never send to pfsense lan interface to be policy routed out?

          What is the point of the openvpn rule on your lan - that would ever been seen since you have a lan net rule any any above it.

          An intelligent man is sometimes forced to be drunk to spend time with his fools
          If you get confused: Listen to the Music Play
          Please don't Chat/PM me for help, unless mod related
          SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1

          1 Reply Last reply Reply Quote 0
          • S Offline
            Spiffster
            last edited by

            @johnpoz:

            I don't see any hits on that rule for 192.168.5.12 as source.. Is that 192.168.5 a downstream network?  Maybe the device has a different gateway set so it would never send to pfsense lan interface to be policy routed out?

            Its a pretty basic setup. Every device on the HQ network (192.168.5.x) has this pfSense box as its GW. From what I understand is pfSense matches ANY traffic from that IP(192.168.5.12) and redirects it through the MPLS gateway… and on the other end (192.168.2.x) that pfSense box redirects any traffic to that IP(192.168.5.12) through the MPLS as well.

            I dont see how this is asymmetric, but its apparently blocking the TCP:AS packets for that reason.

            @johnpoz:

            What is the point of the openvpn rule on your lan - that would ever been seen since you have a lan net rule any any above it.

            That was put there by some wizard I ran a while back. I can remove it.

            1 Reply Last reply Reply Quote 0
            • johnpozJ Offline
              johnpoz LAYER 8 Global Moderator
              last edited by

              "From what I understand is pfSense matches ANY traffic from that IP(192.168.5.12) and redirects it through the MPLS gateway"

              But its not or there is no traffic.. Your rule shows NO hits that 0 currently, and total its only moved a whole 12KB..

              How are these connected?  Are you natting at the mpls connections at both ends?

              An intelligent man is sometimes forced to be drunk to spend time with his fools
              If you get confused: Listen to the Music Play
              Please don't Chat/PM me for help, unless mod related
              SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1

              1 Reply Last reply Reply Quote 0
              • S Offline
                Spiffster
                last edited by

                Yes, and I am probably missing something stupid but I dont know what… that traffic happily traverses the VPN from HQ to remote sites.

                Normally:

                192.168.5.12(phone server) <--> 192.168.5.1 <--> OpenVPN <--> 192.168.2.1 <--> 192.168.2.47(phone)

                I would like OpenVPN to be replaced with MPLS... seems like this should be pretty straight forward.

                I could do this entirely without pfSense by manually setting the phone server GW to 192.168.5.254(MPLS GW) and manually setting all remote phone GW to their local MPLS router eg: 192.168.2.254:

                192.168.5.12(phone server) <--> 192.168.5.254 <--> MPLS <--> 192.168.2.254 <--> 192.168.2.47(phone)

                But this is not feasible and would not allow for failover.

                1 Reply Last reply Reply Quote 0
                • johnpozJ Offline
                  johnpoz LAYER 8 Global Moderator
                  last edited by

                  Mpls is not a tunnel.  there has to be routes that say hey to get to 192.168.x go here

                  192.168.5.12(phone server) <–> 192.168.5.254 pfsense mpls_IP?? <--> MPLS <--> mpls_IP? pfsense 192.168.2.254 <--> 192.168.2.47(phone)

                  An intelligent man is sometimes forced to be drunk to spend time with his fools
                  If you get confused: Listen to the Music Play
                  Please don't Chat/PM me for help, unless mod related
                  SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1

                  1 Reply Last reply Reply Quote 0
                  • S Offline
                    Spiffster
                    last edited by

                    I do realize these are quite different technologies (private circuit vs internet VPN), but I can connect to each remote office through either. Its nice because I can work on the pfSense boxes remotely without the risk of losing my connection. I use MPLS as a backdoor of sorts, so if I hose a pfSense box I dont have to drive out to the remote office, I can just use a static route to a remote VM that has the MPLS router as its default GW. One doesnt rely on the other in this setup, I just want to re-route VoIP traffic over MPLS via pfSense.

                    Not sure if its worth mentioning, but the pfSense system at HQ is a CARP setup. Each remote location just have a single pfSense VM.

                    1 Reply Last reply Reply Quote 0
                    • johnpozJ Offline
                      johnpoz LAYER 8 Global Moderator
                      last edited by

                      What part do you not understand about the mpls IPs??  And your natting to them.. WHAT are the mpls IPs - how does the mpls network know where 192.168.5 is??  Does it?

                      I would assume your natting to this mpls network??

                      An intelligent man is sometimes forced to be drunk to spend time with his fools
                      If you get confused: Listen to the Music Play
                      Please don't Chat/PM me for help, unless mod related
                      SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1

                      1 Reply Last reply Reply Quote 0
                      • S Offline
                        Spiffster
                        last edited by

                        I apologize for leaving information out but I am not natting anything on MPLS… Each of our four sites have an MPLS router (Adtran 908e) managed by Windstream. As far as I know (and obviously I dont know shit about MPLS) the MPLS routers are connected to one another via a private circuit. Our pfSense at each location just list MPLS as an additional GW. Under System-> Routing I have:

                        Comcast (default)
                        Windstream
                        MPLS

                        Here are some tracert output from my pc on the 192.168.5.x (HQ) network:
                        Using default GW: (pfSense OpenVPN)

                        tracert 192.168.2.20
                        1    <1 ms    <1 ms    <1 ms  192.168.5.2
                        2    16 ms    14 ms    14 ms  10.5.2.2
                        3    17 ms    14 ms    14 ms  192.168.2.20

                        Using GW 192.168.5.254 (Adtran Router MPLS)

                        tracert 192.168.2.55
                        1    1 ms    <1 ms    <1 ms  192.168.5.254
                        2    3 ms    3 ms    3 ms  216.43.148.141
                        3    *        *        *    Request timed out.
                        4    3 ms    3 ms    3 ms  63-253-248-153.mcleodusa.net [63.253.248.153]
                        5    15 ms    10 ms    12 ms  63-253-248-154.ip.mcleodusa.net [63.253.248.154]
                        6    14 ms    13 ms    13 ms  192.168.2.55

                        I hope this helps to clarify things. Sorry if im being a PITA.

                        1 Reply Last reply Reply Quote 0
                        • johnpozJ Offline
                          johnpoz LAYER 8 Global Moderator
                          last edited by

                          So yeah your natting…  What does the IP address of your mpls interface say is its IP?  And post up your outbound NAT page..

                          An intelligent man is sometimes forced to be drunk to spend time with his fools
                          If you get confused: Listen to the Music Play
                          Please don't Chat/PM me for help, unless mod related
                          SG-4860 25.07.1 | Lab VMs 2.8.1, 25.07.1

                          1 Reply Last reply Reply Quote 0
                          • S Offline
                            Spiffster
                            last edited by

                            @johnpoz:

                            So yeah your natting…  What does the IP address of your mpls interface say is its IP?  And post up your outbound NAT page..

                            FWIW, looking at the router config for that MPLS circuit I do see an MPLS VPN setup. I dont see a NAT config.

                            Anyway, I do appreciate your help but I think the solution in my case would be to just change the Avaya IPO Server's gateway to the 192.168.5.254 (MPLS Router) from 192.168.5.1 (pfSense FW) which will eliminate the asymmetric route issue.

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