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

    New NAT rules not working

    NAT
    2
    17
    8.0k
    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.
    • jimpJ
      jimp Rebel Alliance Developer Netgate
      last edited by

      Follow the procedures here:
      http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

      It always boils down to one of those… the packet capture and logs would be more helpful to see.

      You can also check the state table (Diag > States) to see if the connection shows up there. Your firewall rule is not set to log, so a successful connection wouldn't show in the logs.

      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
      • D
        dedoz
        last edited by

        I've attached the screenshot for:

        block Mar 28 12:36:35 WAN_FIBER 50.17.118.102:60588 192.168.1.12:22 TCP:S

        I've already followed the link you posted with no luck so far .

        From Diag->States nothing shows up for port 22 from 50.17.118.102.

        Please let me know if I can get more logs or any other sort of information to track this down

        Thanks!

        img3.jpg
        img3.jpg_thumb

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

          That implies that your NAT rule matched but the firewall rule did not, since it shows the translated address in the log entry.

          Even though it says "default deny" - have you tried disabling the "block bogon networks" rule on WAN_FIBER to see if it gets through?

          Other than that, we'd need to see /tmp/rules.debug to see if the actual rule does match up with what the GUI shows.

          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
          • D
            dedoz
            last edited by

            Thanks jimp, kind of stuck here, this is all I've got from rules.debug:

            rdr on xl0 proto { tcp udp } from 50.17.118.102 to 190.16.xxx.xxx -> 192.168.1.12

            Which seems OK to me, but nothing else. I'm pretty sure there is nothing in front of the pfsense that could be blocking the traffic, actually this rule stopped working after I deleted it and had it re-created.

            Anything else I can try or provide to track this down?

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

              There should also be a "pass" line that corresponds to the same source and target IP/port.

              The rdr is only the NAT portion of the forward, the firewall rule should be there also.

              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
              • D
                dedoz
                last edited by

                You are right, the "pass in" it is supposed to be there but is not, even though it's in the GUI.

                I've tried again re-creating the rule, it appears both in the GUI (NAT/FW) but then only the rdr shows up in the rules.debug, something isn't working really well here.

                1 Reply Last reply Reply Quote 0
                • D
                  dedoz
                  last edited by

                  This is kind of weird: while looking at rules.debug, found very ancient rules that aren't any longer on the GUI and were deleted long time ago.

                  In the other hand, newer rules weren't also there but the NAT part only, not the associated FW rule.

                  I've managed to accomplish what I needed ASAP by modifying the rules.debug file and reloading the configuration, which of course isn't reflected in the Web GUI.

                  Definitely there is something wrong with this, and I need to fix it, there is no way we can trust we see from the GUI, and having to do the changes via the CLI is kind of annoying.

                  Any ideas/help are more than welcome!

                  Thanks!

                  1 Reply Last reply Reply Quote 0
                  • D
                    dedoz
                    last edited by

                    Rules do not work via the webConfigurator, they do work if I apply them by changing and reloading rules.debug which isn't the best way for doing this.

                    Now of course, webConfigurator and rules.debug do not match.

                    Even new rules from webConfigurator do not get created on rules.debug, just the NAT ones.

                    Anyone?

                    1 Reply Last reply Reply Quote 0
                    • D
                      dedoz
                      last edited by

                      Seems like a dead post, no idea what's going on here with the GUI and rules.

                      Suddenly the firewall crashed yesterday and rebooted on it's own, where can I send the crash report?

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

                        use the button in the GUI to submit the crash report and let us know the date/time it was submitted.

                        I'm not sure why just the firewall rules aren't making it to your rules.debug, though the most likely scenario is a package hooking into the rules process that is not doing something correctly.

                        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
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.