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

    NAT Port forwarding not working ?

    Scheduled Pinned Locked Moved NAT
    12 Posts 5 Posters 6.8k 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.
    • D Offline
      darkm00n
      last edited by

      Hello,

      It would be great if somebody can help me :)

      My problem is the fact I created a NAT inbound port forwarding rule in order to forward to an internal IP address the traffic for destination port 8254 on my public address (1.1.1.1 below).
      IP 178.237.87.67.0 > 1.1.1.1.8254: UDP, length 1316

      I see the traffic reaching 1.1.1.1 but it seems that nothing is forwarded to my internal host. Moreover, I tried to activate the logging on the firewall rule and nothing comes into the logs.

      I have the impression that because source port is 0 that PFSense NAT is dropping the packets.

      I also can confirm that internal host do not receive any traffic, as I run a network trace on internal host.

      I tried to enable or disable NAT reflection on the rule, nothing is different.

      I'm a bit stuck here and therefor ask if somebody would be able to help me to sort this out.
      Many thanks in advance.
      Cheers

      1 Reply Last reply Reply Quote 0
      • G Offline
        gderf
        last edited by

        You should show both the NAT and the matching Firewall rule as displayed in pfsense. There are two parts to this.

        A NAT involving port 0 looks questionable to me, as does an internal IP of 1.1.1.1.

        1 Reply Last reply Reply Quote 0
        • D Offline
          darkm00n
          last edited by

          Here are the real IPs… (1.1.1.1 was a replacement..)

          Below : capture of packets coming to wan interface.. We see that packets with source port 0 are coming for a destination of port 8254

          18:39:07.491938 IP 178.237.87.xxx.0 > 78.155.2.xxx.8254: UDP, length 1316
          18:39:07.493880 IP 178.237.87.xxx.0 > 78.155.2.xxx.8254: UDP, length 1316
          18:39:07.495279 IP 178.237.87.xxx.0 > 78.155.2.xxx.8254: UDP, length 1316

          At pfsense level, the NAT rule is set as below:
          WAN TCP * * WAN address 8254 - 8260 192.168.1.28 8254 - 8260 Nat IN

          And the firewall rule :
          TCP * * 192.168.1.28 8254 - 8260 * none

          What I don't understand is why pfsense is not pushing the packages to 192.168.1.28...(I made a capture there and saw nothing coming, even if the packages are arriving on the WAN inteface)

          Cheers
          DM

          1 Reply Last reply Reply Quote 0
          • G Offline
            gderf
            last edited by

            Well, you have UDP packets arriving at your WAN interface, but your NAT and Firewall rule are for TCP.

            1 Reply Last reply Reply Quote 0
            • D Offline
              darkm00n
              last edited by

              wrong copy paste…
              even if my NAT and FW rules are for UDP or TCP/UPD, the result is the same. Nothing pushed over to internal machine...

              Problem is clearly linked to PFSense, because if I try an other firewall (IPFire i.e.) the port forwarding works...

              Anybody got idea about how to debug this ?
              Txxx in advance.

              1 Reply Last reply Reply Quote 0
              • D Offline
                darkm00n
                last edited by

                Nobody can help ? :(

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

                  Your port forwarding and firewall rules look fine.  There must be another reason for the issue.

                  What is the IP address of your firewall's LAN port?  Do you have anything between the LAN port and the device you are trying to forward ports to?  Do you have any other firewall rules which could be interfering with those ports?

                  A source port of 0 from the sender does seem odd.  Are you able to test using a different sender?

                  1 Reply Last reply Reply Quote 0
                  • D Offline
                    darkm00n
                    last edited by

                    Thanks for feedback.
                    The ip of FW lan port is 192.168.1.28 (internal device).
                    There is not firewall in between pfsense and the internal device.
                    If i run an other firewall (IPFire) than PFSense, port forwarding works properls.
                    This is true that a source port of 0 is weird but this is the way my provider send the IPTV streams… With a different sender (like SIP protocol) the forwarding on pfsense works.
                    I really have the impression that pfsense is not able to manage a port forwarding for incoming traffic having a source port of 0... Maybe a bug ?

                    1 Reply Last reply Reply Quote 0
                    • C Offline
                      cmb
                      last edited by

                      We block everything using port 0 with a hard coded rule that cannot be disabled (short of editing the source). Port 0 is a reserved port that per spec should never be used. They're violating network standards if they're actually using port 0.

                      I'd gripe that they're doing stupid, broken things, but the chances of any provider actually doing anything about that are probably slim. You can take out the block rules for port 0 in /etc/inc/filter.inc:

                      block quick inet proto { tcp, udp } from any port = 0 to any
                      block quick inet proto { tcp, udp } from any to any port = 0
                      block quick inet6 proto { tcp, udp } from any port = 0 to any
                      block quick inet6 proto { tcp, udp } from any to any port = 0

                      and reload the ruleset by running /etc/rc.filter_configure_sync

                      You'll have to make the same source change after every upgrade. That's not something we're going to make configurable unless a whole lot of people start violating standards. This is the first port 0 usage case we've ever seen and those rules have been there for many years.

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

                        @darkm00n:

                        The ip of FW lan port is 192.168.1.28 (internal device).

                        I looked again after seeing this and your NAT rule is set to send the data to the firewall's internal interface.  Is that what you are trying to do?  It won't go anywhere after that unless you have a service running on the firewall, which is bound to the internal interface and listening on that port.

                        If you are trying to send it to another device on the network, the NAT rule should have a destination of that device's IP address, not your firewall's internal IP.

                        1 Reply Last reply Reply Quote 0
                        • D Offline
                          darkm00n
                          last edited by

                          Thanks for all your replies !

                          @Syntax42, my NAT rule is sending to internal device (.28) and not to firewall interface.

                          @cmb, this sounds like you mention. I don't know why my provider send UDP stream with source port 0 which is non-standard/violating network standards.
                          The packet capture on the WAN FW interface clearly shows that source port is 0.. (see below).
                          18:39:07.491938 IP 178.237.87.xxx.0 > 78.155.2.xxx.8254: UDP, length 1316
                          I'll try to take out the block rules for port 0 in /et/inc/filter.inc file and reload the ruleset like you mention below.

                          Many thanks again !!

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

                            I just had the exact same issue. I removed the rule for port = 0 and the "replay TV" and "start over" features of my CATV provider are now working fine :) Actually it seems to be from the same provider than darkm00n… I will try to contact my ISP/CATV provider about this issue but I fear they won't care about it :-\

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