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 70.2k 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.
    • E Offline
      erisan500
      last edited by

      Still didn't see a clear answer.
      Is this the way the outbound nat rule should look like?

      WAN  10.0.10.0/24 * * 5060 WAN address * YES SIP - LAN to WAN

      My voip server is on the 10.0.10.0 network.

      Eric

      1 Reply Last reply Reply Quote 0
      • E Offline
        erisan500
        last edited by

        no one ??

        1 Reply Last reply Reply Quote 0
        • L Offline
          lloydbuchanan
          last edited by

          I must share the frustration expressed by others with this issue.

          NAT rule to forward all UDP traffic from the VOIP provider to the Trixbox(Asterisk). Outbound calls from the Trixbox work fine.  Inbound trunk calls all fail.

          Wireshark monitoring shows SIP INVITEs coming into the WAN interface and NOTHING going out the LAN interface.  The packets are being eaten by pfsense.  No port rewrites.  No nothing.

          Tried the suggestions in this thread to no effect.  If I had hair…

          1 Reply Last reply Reply Quote 0
          • jimpJ Offline
            jimp Rebel Alliance Developer Netgate
            last edited by

            If it doesn't work, then something must have been misconfigured/overcomplicated/enabled without knowing it would conflict.

            Go over every point in https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting and make sure you have it all correct.

            Seeing the SIP invites hit WAN in a capture tells you very little - your NAT rule could still be wrong/not matching, or firewall rules, or some other part of the puzzle.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • L Offline
              lloydbuchanan
              last edited by

              Thanks for the reply.  Went through the list. Still puzzled.

              The Trixbox continues to register correctly with the VOIP carrier through that port.

              NAT and Firewall rules attached, but they don't seem terribly complicated.  Similar rules work flawlessly for other services.

              The incoming packets definitely have the correct IP source and destination, UDP and port 5060.  There are some differences between the registration packets that traverse pfsense and the invitations that do not.

              The envelope has [DF] set (but does not appear fragmented and I selected the strip [DF] on fragmented packets option). It also has tos=0x010 for what that's worth.

              pf.png
              pf.png_thumb
              rule.png
              rule.png_thumb

              1 Reply Last reply Reply Quote 0
              • jimpJ Offline
                jimp Rebel Alliance Developer Netgate
                last edited by

                Is the traffic actually being sourced from an IP in the Junction alias?

                If you check the state table, is a state created when a call tries to come in?

                Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                1 Reply Last reply Reply Quote 0
                • L Offline
                  lloydbuchanan
                  last edited by

                  Yes, the source IP is in the Junction alias. 
                  Good idea checking the states table.  :)  None is created.

                  1 Reply Last reply Reply Quote 0
                  • jimpJ Offline
                    jimp Rebel Alliance Developer Netgate
                    last edited by

                    No state confirms that the rule is not being matched. If it were matched, you'd have a state.

                    Look in the firewall logs - if you see a block to the public IP - then the NAT didn't match
                    If you see a block to the private IP - the NAT matched but somehow the firewall rule did not.

                    Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                    Need help fast? Netgate Global Support!

                    Do not Chat/PM for help!

                    1 Reply Last reply Reply Quote 0
                    • W Offline
                      webjam
                      last edited by

                      I just ran into this issue on the latest firmware.  Some packets forward and some don't in sip.  Identical ssh forward rule to the same host work perfectly.

                      1 Reply Last reply Reply Quote 0
                      • I Offline
                        iwm911
                        last edited by

                        Hi,

                        i know that its been a while sense the last post but i got the same problem and a possible solution.

                        so the problem for me was that i set up a nat rule the translate every incomming udp packet to port 5060 on my wan IP address to my internal asterisk box.
                        my sip provider have my IP address so i dont even need to register, he just sends me invites when i have a call from the PSTN.

                        i couldn't get incoming calls. when i called my PSTN number i could see the invite packets on my pppoe0 interface but no packets were sent to my DMZ interface.

                        i did a little test and tried to send a udp packet from my home computer to the pfsense to port 5060, to my wonder it worked and the packet was sent to the DMZ interface and reached the asterisk machine.

                        after some more digging around (and rebooting the asterisk and pfsense) i decided to look for the connection state (under Diagnostics –> States).
                        i searched for my SIP provider and found 2 states, one incoming and one outgoing.
                        i don't remember the exact state they were in (i think that the incomming was direct from the SIP provider to the asterisk, without the WAN ip in the middle, but i could be mistaken).

                        anyhow, after deleting the 2 states i tried to dial my PSTN number and it worked.
                        all packets flowed and my call was received by the PBX and eventually the SIP phone :-)

                        for right now its working but i don't know if it will last (i hope it will).

                        keep you guys posted.

                        1 Reply Last reply Reply Quote 0
                        • K Offline
                          kejianshi
                          last edited by

                          Are you using manual outbound NAT and static port on 5060, 5061 and all the sip related transport ports?

                          1 Reply Last reply Reply Quote 0
                          • I Offline
                            iwm911
                            last edited by

                            Automatic outbound Nat
                            Regular inbound Nat from wan IP to server ip on port 5060 udp and another Nat rule for the rtp.

                            1 Reply Last reply Reply Quote 0
                            • K Offline
                              kejianshi
                              last edited by

                              Static port setting on the manual outbound NAT for sip related ports….  First in list.

                              1 Reply Last reply Reply Quote 0
                              • U Offline
                                unknown001
                                last edited by

                                I'm glad I found this thread, it cleared up some mystery for me. I remember back in 2012, I was pulling my hair out because of this issue. Spent long hours reconfiguring/reconfiguring pfsense. It never worked so I went to a different router/firewall.

                                I like pfsense, the interface, the lightweight os, the robustness (compatibility); But because of this SIP port-forwarding behind pfsense problem, I'm not using pfsense in production. My 2010 linksys wireless router did not have this issue, port-forwarding for sip worked fine there. Wondering if 2.2 fixed this issue. If it did, I'll give pfsense another try.

                                1 Reply Last reply Reply Quote 0
                                • K Offline
                                  kejianshi
                                  last edited by

                                  I'm still a bit baffled what is so hard about port forwarding, manual outbound NAT and static port.

                                  1 Reply Last reply Reply Quote 0
                                  • jimpJ Offline
                                    jimp Rebel Alliance Developer Netgate
                                    last edited by

                                    Since the time of this old thread, we have added the following doc to the wiki:

                                    https://doc.pfsense.org/index.php/PBX_VoIP_NAT_How-to

                                    Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                    Need help fast? Netgate Global Support!

                                    Do not Chat/PM for help!

                                    1 Reply Last reply Reply Quote 0
                                    • K Offline
                                      kejianshi
                                      last edited by

                                      Thats awesome.  Should help the new guys alot.

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