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

    NAT Port Forwarding to Internal host UDP port 5060 not working as expected

    Scheduled Pinned Locked Moved NAT
    69 Posts 22 Posters 68.6k 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.
    • C
      cmb
      last edited by

      You need to rewrite the source port on your outbound SIP as is done by default. I suspect the outbound NAT state is picking up the traffic rather than the rdr (port forward), because you aren't rewriting the source port.

      1 Reply Last reply Reply Quote 0
      • N8LBVN
        N8LBV
        last edited by

        You need to rewrite the source port on your outbound SIP as is done by default.
        Sorry I'm not understanding exactly what you are saying here.
        If I use it in a default fashion while outbound sip is being rewritten I am seeing the problem with inbound packets to port 5060 which is wrong.
        A remote host can send inbound packets to multiple ports there is nothing wrong with this.

        I suspect the outbound NAT state is picking up the traffic rather than the rdr (port forward), because you aren't rewriting the source port.
        Still not understanding at all (sorry). And we are dealing with an inbound static rule so outbound nat state should not matter.

        I still have an expectation as it works on all other firewalls and that is if you define a port forward rule it will work regardless of what is going on
        dynamically.

        I still see no reason at all why this is not portwarding under all conditions. That is the sole purpose of port forwarding. Seriously.. there's no reason for it NOT to work unless
        there is a bug in the packet inspection and/or decision making here.. It's a brain dead simple port forwarding task and it's failing.

        I feel more like I do now.

        1 Reply Last reply Reply Quote 0
        • N8LBVN
          N8LBV
          last edited by

          CMB, it sounds like you are telling me what I need to do to make it work (which I have done) and have made it work awhile back.. maybe you already read this.. I'm not sure.  I have done exactly that and it does work. But portworwarding itself in this case still does not behave the way I expect it should.
          It breaks other things that I won't dig into right now unless you ask, as it will take this off topic.
          I'll continue to listen & learn for awhile before I open a bug report in case I'm missing something.  Thank you
          so very much for helping out!

          I feel more like I do now.

          1 Reply Last reply Reply Quote 0
          • P
            phazethree
            last edited by

            I am having a similar problem but I can at least get it to work using Manual NAT. The problem with this is once I turn on manual NAT with Static, it breaks my other subnets web browsing capabilities.

            Here is my scenario:

            192.168.0.0 - Local lan
            192.168.1.0 - VPN lan
            192.168.12.0 - MPLS lan
            192.168.13.0 - MPLS lan
            192.168.14.0 - VPN lan
            192.168.23.0 - VPN Lan
            192.168.24.0 - VPN lan
            192.168.25.0 - VPN lan
            192.168.26.0 - VPN lan

            The phone system sits on 192.168.0.6 and there are IP phones on 192.168.23.0 and 192.168.25.0 working fine. We had to add a SIP provider for routing "out of area" numbers to the phone system from the phones sitting on the  192.168.14.0 network. The intercom traffic works fine between 192.168.0.0 and 192.168.14.0 through the VPN. All HTTP traffic works fine through squid3 as a proxy from all networks. With this currently set as Auto Outbound NAT everything works fine except the SIP traffic. I can call the number, the packets get routed through the phone system and the phones at 192.168.14.0 ring. I can hear them answer but they cannot hear me. To resolve this I turned on Manual Outbound NAT. Fixed the phone issue, but now no one can access web pages through squid3 on any network other than 192.168.0.0 which is local to the firewall and the phone system.

            I have come to the conclusion that the Static Port option breaks squid3 but fixes the phones, and in turn static mapping turned off fixes squid3 but breaks the phones (one way audio). We are using an outside provider so there are no SIP equipment onsite.

            Any one have any suggestions or need further info please feel free. I'm at the point I'll try anything now.

            1 Reply Last reply Reply Quote 0
            • F
              friesen
              last edited by

              i am having the exact same problem as N8LBV.  i have been using voip through pfsense for years with no problems until setting up a new box with version 2.0.1 of pfsense.  something isnt right.  i have tried all the suggestions for outbound static ports and anything else that people suggest in various forums and still no love.  why can't this version of pfsense just not forward udp traffic that originated from behind the firewall back to it on port 5060 to my voip server?  i can connect to my server through port 5060 on a sip client that originates on the wan connection, but not a connection that originated from behind pfsense, i hope that makes sense.

              1 Reply Last reply Reply Quote 0
              • F
                friesen
                last edited by

                I finally got mine working today. i reset everything to factory defaults.  created a nat port forward
                WAN TCP/UDP * * WAN address 5060 (SIP) 10.0.0.8 5060 (SIP) and allowed it to create a new associated filter rule for that.  under NAT.outbound i changed it to manual and set it to use static-port, reloaded my trunk and inbound calls worked.

                1 Reply Last reply Reply Quote 0
                • C
                  chinny.ha
                  last edited by

                  hi all,

                  i also have the exact same issue – 9 packets arriving on wan, 2 arriving at interior host.

                  i'm running a pfsense 2.01 host on amd64 inside a vmware virtual machine.

                  seriously grave -- i cannot seem to get the packets forwarded following the advice in this thread :-(

                  c

                  1 Reply Last reply Reply Quote 0
                  • G
                    giulianoz
                    last edited by

                    Same issue here. Unfortunately the tips above didn't worked for me :( Any suggestion ?

                    1 Reply Last reply Reply Quote 0
                    • G
                      giulianoz
                      last edited by

                      it seems to work on 2.1 snapshot of july 18th

                      1 Reply Last reply Reply Quote 0
                      • I
                        inflamer
                        last edited by

                        N8LBV,

                        does the SIP UA on the inside of your pfSense implement rport? If not, I would expect that SIP responses coming back from the SIP server on the outside will be sent to the port specified in the via header inserted by the SIP UA on the inside of your network, which for SIP over UDP normally would be 5060.

                        Can you post a packet capture showing an outbound SIP request and the corresponding response which is coming back on the wrong port?

                        1 Reply Last reply Reply Quote 0
                        • I
                          inflamer
                          last edited by

                          N8LBV,

                          also keep in mind that while SIP responses use via headers for making it back to the originator, new requests within the same transaction (Such as the ACK request you mentioned in your initial post) use record-route headers for making it to their destination, which could explain why some SIP responses/requests are not arriving at the same port as the outbound traffic used.

                          1 Reply Last reply Reply Quote 0
                          • G
                            gofast
                            last edited by

                            I am also having the exact same problem. A brain dead port forward on UDP port 5060 is not working. I have been pulling my hair out trying everything. Packet captures on the pfsense show that the retuning packets never get forwarded from with WAN to LAN, i.e. are on WAN but never on LAN. I reset to defaults and added just the simple rule and still no joy.

                            1 Reply Last reply Reply Quote 0
                            • I
                              inflamer
                              last edited by

                              Gofast,

                              have you verified that the response is coming back to the same port as the original request was sent out from?

                              If the involved SIP UA's do not support the 'rport' SIP extension then the responses would be sent back to the port specified in the topmost via header, which would normally not be the same port as the NAT'ed port the original request was sent out with.

                              • Andreas
                              1 Reply Last reply Reply Quote 0
                              • G
                                gofast
                                last edited by

                                The source and dest port were 5060 from the asterisk box for the packet on the LAN being sent to the internet(WAN).
                                The source port got changed via the outgoing NAT to the WAN. The return packet from the internet had source and dest ports of 5060. The port forward should forward this regardless because it met the rule - destination port 5060 on wan forward to an ip on the LAN. I firewall added rules to allow all on all interfaces and it doesn't help. It appears to just get dropped for an unknown reason (unknown to me). Why does the port forward get ignored? What came before shouldn't matter as UDP is stateless. Am I missing something?

                                1 Reply Last reply Reply Quote 0
                                • I
                                  inflamer
                                  last edited by

                                  Gofast,

                                  can you post screenshots of the NAT PFW rule and the associated firewall rule?

                                  1 Reply Last reply Reply Quote 0
                                  • G
                                    gofast
                                    last edited by

                                    I can post tomorrow as I don't have access right now. The 2.01 seem to have a bug that changing the fwd rule from tcp to udp didn't update the auto created filter to udp (and you couldn't edit it). This didn't seem to occur in 2.1. Ether way with the rules+filter created correctly I couldn't make it work.

                                    It was created with the following settings
                                    protocol udp
                                    destination port 5060 - 5060
                                    target ip - lan ip of voip box i.e. 10.x.x.x
                                    target port 5060
                                    everything else was default i.e. Interface - wan, destination - wan address, create associated rule, no source options selected.

                                    Diagnostics / packet capture showed packets sending & receiving on wan but only packets destined for internet on lan. tcpdump on voip box also confirmed this. The wan is a pppoe to modem in bridge mode.

                                    I also tried manual outgoing nat, adding rues to allow everything on all interfaces, advanced options - Bypass firewall rules for traffic, Disable the PF scrubbing option,  Reflection on/off

                                    1 Reply Last reply Reply Quote 0
                                    • G
                                      gofast
                                      last edited by

                                      I can't get port forwards on UDP port 5060. I can get a mail server, pptp server, terminal server, web server all working (TCP and TCP + GRE for PPTP), but not VOIP on UDP.
                                      Here are the packet captures from the interfaces.

                                      10.X.X.X is my VOIP box address on the LAN
                                      122.X.X.X is the WAN address
                                      213.X.X.X is the VOIP providers address

                                      Packet captures on the voip box on the LAN - I can only see packets being sent to the VOIP provider…
                                      20:00:37.425557 IP 10.X.X.X.5060 > 213.X.X.X.5060: SIP, length: 648
                                      20:00:38.425626 IP 10.X.X.X.5060 > 213.X.X.X.5060: SIP, length: 648
                                      20:00:40.425756 IP 10.X.X.X.5060 > 213.X.X.X.5060: SIP, length: 648
                                      20:00:44.426029 IP 10.X.X.X.5060 > 213.X.X.X.5060: SIP, length: 648

                                      packet captures on the pfsense on the WAN if - I can see packets being sent to the VOIP provider...and responses back.
                                      20:22:14.587253 IP 122.X.X.X.56607 > 213.X.X.X.5060: UDP, length 514
                                      20:22:14.634733 IP 213.X.X.X.5060 > 122.X.X.X.5060: UDP, length 455
                                      20:22:14.816183 IP 122.X.X.X.56607 > 213.X.X.X.5060: UDP, length 514
                                      20:22:14.863381 IP 213.X.X.X.5060 > 122.X.X.X.5060: UDP, length 455

                                      packet captures on the pfsense on the LAN again only show packets being sent to the VOIP provider.
                                      20:24:21.581862 IP 10.X.X.X.5060 > 213.X.X.X.5060: UDP, length 514
                                      20:24:21.808852 IP 10.X.X.X.5060 > 213.X.X.X.5060: UDP, length 514
                                      20:24:24.543081 IP 10.X.X.X.5060 > 213.X.X.X.5060: UDP, length 648
                                      20:24:28.543369 IP 10.X.X.X.5060 > 213.X.X.X.5060: UDP, length 648

                                      I've attached a screenshots of the NAT rule. I've used the auto created firewall rule. I've tried the latest build, allowing everything from anywhere to anywhere of any type on everything, manual nat with static port, nothing helps. Nothing in the logs either. The responses appear to be just dropped for no apparent reason. Anyone have any idea what I should try next? Oh and it works on my Cisco 877.

                                      Capture0.PNG
                                      Capture0.PNG_thumb

                                      1 Reply Last reply Reply Quote 0
                                      • I
                                        inflamer
                                        last edited by

                                        gofast, perhaps you could try changing the NAT rule to have a 'Dest.addr' of 'WAN address' instead of the manually input 122.x.x.x IP address?

                                        If you have a static WAN IP it shouldn't make any difference I guess, but if your WAN is using DHCP, it would be safer to have 'Dest.addr' set to 'WAN address' since that alias would always be your current WAN IP address.

                                        1 Reply Last reply Reply Quote 0
                                        • G
                                          gofast
                                          last edited by

                                          Hi,

                                          It is a static ip address so yes it shouldn't make any difference. The wan connection is pppoe to a modem in bridge mode. Anyway you can see from the packet capture that the packets are arriving back with the correct address. All other tcp connections nat just fine. How do I log a bug for this? I'm thinking of setting up a virtual environment to replicate the problem for the developers. What vitalisation technology should I use for this? Virtual box? I suspect this is the same issue I get with pptp connections sometimes not working. Perhaps the same problem with udp packets is affecting gre packets? (also stateless packets). Also how can I access the full nat table (not just the summary)?
                                          I've spent many hours on this and am sure it is a bug. I've reset to defaults, upgraded to latest release, etc. etc. etc. If the rule says nat the packet and it matches the rule and is not being filtered, Why isn't it working  ???

                                          Regards,
                                          Tony

                                          1 Reply Last reply Reply Quote 0
                                          • L
                                            launch3
                                            last edited by

                                            Hey guys saw this is a recent thread and I am having the exact same issue. I tried upgrading to 2.1 but still having the issue. I've tried port forwarding, ive tried static outgoing nat, set the firewall to conservative, still no dice. I am having an issue with the FreeSWITCH pbx behind the firewall where incoming calls drop after exactly 32 seconds. Doing packet caps, I traced it to the firewall not forwarding SIP 'ACK' packets along to the pbx. I've attached the flow of 3 packet caps - one on the pfsense lan, one on wan, and one on the pbx. I have phones registered directly to the ip trunk carrier now as a workaround since my pbx is not fully functional due to this issue. In the packet caps the phones all ring for about a half second then the PBX auto-answers and routes to the IVR menu so the phones stop ringing after half a ring. You can see in the packet caps that the phones receive the incoming ACK packets fine, and note that the phones are using random ports, while the PBX is always using 5080. Maybe this has something to do with it?
                                            Please note that the LAN capture and WAN capture were done for different calls, as I did not know how to do both at once with pfSense. The PBX capture was done at the same time as the pfSense WAN capture IIRC.

                                            Edit: Removed the images as they are not really relevant to this thread. We somewhat solved our issue as you can see below, but I plan to do some more testing with the static nat options and such to see if my install exhibits the same behavior as the OP's.

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