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

    NAT Rule problem

    Scheduled Pinned Locked Moved Firewalling
    18 Posts 4 Posters 5.1k 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.
    • T
      thafener
      last edited by

      Clarknova,

      Thanks for the hint, checking port 22 on the link prorovided I get "stealth" as a result.
      Yes I have checked the box that automatically creates the FW rule and I did not change
      the protocols or IP adresses (see screenshot)

      It confuses me that I can see SSH packets in the log (see screenshot) but I cannot
      connect, what of course works fine from the LAN side.

      Further tips anyone ?

      thx hafnix

      fwlog.jpg
      fwlog.jpg_thumb
      fwrule.jpg
      fwrule.jpg_thumb

      1 Reply Last reply Reply Quote 0
      • E
        Efonnes
        last edited by

        If they aren't already, those firewall rules should be on WAN.  Also, this probably has nothing to do with it, but on the port forward you do not need to set the external address to any unless you have multiple WAN IP addresses and are trying to forward the port on all of them.

        1 Reply Last reply Reply Quote 0
        • T
          thafener
          last edited by

          Yes Efonne, they are on WAN

          1 Reply Last reply Reply Quote 0
          • E
            Efonnes
            last edited by

            Do you have any firewall rules above those that might be blocking it?

            1 Reply Last reply Reply Quote 0
            • T
              thafener
              last edited by

              No, just the ones created by the system and a rule to block Bittorrent 6969

              1 Reply Last reply Reply Quote 0
              • C
                clarknova
                last edited by

                Your first screenshot looks as though pfsense has passed packets coming in on port 22. Very odd then that port 22 appears stealth from the outside world. Do you have a firewall running on your ssh host? Could it be that a host-based firewall is accepting packets from the LAN but not from outside addresses?

                At this point I think tcpdump/wireshark/packet capture is in order to find out where the packets are stopping.

                db

                1 Reply Last reply Reply Quote 0
                • T
                  thafener
                  last edited by

                  Hi again…

                  The SSH host is a Ubuntu 9.10 box with no firewall installed I am using to monitor
                  access points in this network. Connecting to this box from the LAN on Port 22 is
                  no problem at all...

                  Installed Wireshark on this box and let it listen for packets on Port 22 but there
                  was nothing so I think that though the log tells us the packets are passing they
                  are not going through.

                  I already thought about deleting all rules, make a backup of the box and re-install
                  the whole system from the scratch. Do you see any chance that this could help ?

                  Thx hafnix

                  1 Reply Last reply Reply Quote 0
                  • C
                    clarknova
                    last edited by

                    If you're seeing packets arrive at pfsense's WAN, but nothing on the ssh host then they're dieing somewhere in between. There's a good chance your pfsense is misconfigured, or possibly even malfunctioning, and a fresh install could correct that, assuming you don't repeat whatever may have caused the problem in the first place.

                    db

                    1 Reply Last reply Reply Quote 0
                    • T
                      thafener
                      last edited by

                      Ok good I will try that somewhen soon. another proof for this Idea is the console log output :

                      Mar 12 15:01:44 gateway pf: 4\. 327978 rule 102/0(match): pass in on ng0: (tos 0x0, ttl 118, id 55769, offset 0, flags [DF], proto TCP (6), length 48) 217.71.243.136.28170 > 192.168.1.2.22: S, cksum 0x3d8a (correct), 2222965890:2222965890(0) win 65535 
                      

                      Next to this I have tried to reach the target system through a VNN tunnel and turned on logging, once
                      again the logs said Port 22 is going through but still I cannot reach the SSH host.

                      I do not know if there is a problem with the system in general, it is a Intel Atom 330 System on D945GCLF2 board using the onboard
                      Realtek NIC and a 3Com 3C905 NIC in the available PCI slot. Are there known problems with Atom boards or even these NIC's ?

                      Thanks a lot hafnix

                      1 Reply Last reply Reply Quote 0
                      • C
                        clarknova
                        last edited by

                        I believe both those NICs are fairly common in pfsense deployments. The realteks are known for low throughput/high cpu usage, but not necessarily flat out broken, that I'm aware of.

                        You could also do a packet capture on pfsense's LAN interface. If you have equipment between pfsense and Ubuntu this would help eliminate that as cause.

                        db

                        1 Reply Last reply Reply Quote 0
                        • T
                          thafener
                          last edited by

                          Packet Capture was a good plan. Starting a capture on the WAN interface showed packets on Port 22 but there
                          was no output on the LAN interface.
                          There is no equipment between the LAN interface and the target machine that could possibly block traffic.
                          Do you agree that this looks like a internal problem of the pfsense box ?

                          1 Reply Last reply Reply Quote 0
                          • C
                            clarknova
                            last edited by

                            For sure.

                            db

                            1 Reply Last reply Reply Quote 0
                            • T
                              thafener
                              last edited by

                              Ok it works. Deleted all fw-rules, made a backup, reinstalled the box and created the nat rule once more –> works !
                              Thank you all for your hints and support  ;)

                              1 Reply Last reply Reply Quote 0
                              • T
                                thafener
                                last edited by

                                Hi @ll

                                after the NAT rules worked fine over two weeks it has stopped working again and I have the same
                                problem as before.
                                I can see traffic in the logs forwarded to the target host but I cannot connect on Port 22.
                                In between I have made no changes to the system and I did not even restart it what I in
                                fact did today when I noticed the problem again.
                                I mean I have "solved" the problem by reinstalling the box a while ago but this cannot be a
                                solution, no need to say that we do not have a M$ Box here…
                                It is strange in my eyes that this Forum has a lot of posts regarding NAT... all with rather
                                similar problems and no real solution.
                                Further tips anyone ?

                                Thx in advance

                                Thafener

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