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

    how come on a natted port 80 a blocked ip can still telnet in

    Scheduled Pinned Locked Moved Firewalling
    24 Posts 4 Posters 2.5k 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.
    • KOMK
      KOM
      last edited by

      Show the block rule you created.

      G 1 Reply Last reply Reply Quote 0
      • G
        Gerard64 @KOM
        last edited by

        @KOM
        It is deleted now I am done with testing.
        It was the same as the pfblocker block rules.
        It was blocked

        It is not only this test block rule, the block rules of pfblocker show the same behavior thats were i first saw it happen.
        You can see the most pfblocker rules in the wan image.

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

          This image shows what happens wen i open port 80 again.
          The bottom 2 lines is with port 80 removed.
          Wen i add port 80 again you see the top 2 lines connecting to my local webserver.
          While the source ip is still blocked.

          wen port 80 is removed i cannot telnet in from the internet, the outside.
          Wen port 80 is added but the public test ip is blocked i can telnet in while the log says it is blocked to the local ip of the webserver.

          I can not visit any website telnet gives no output other then CONNECTED.
          How can it be connected wen i block the ip?

          firewall-log.jpg

          1 Reply Last reply Reply Quote 0
          • KOMK
            KOM
            last edited by

            Those aren't connections, they're hits on a block rule that shows you the intended destination. With your NAT enabled, it shows you the LAN server that's the destination of the connection attempt. With the NAT disabled, it shows you your WAN address. You can try to telnet but it won't make a connection. To verify, change the block rule to a reject rule. That way your WAN will close the connection instead of letting it timeout, and you will know right away if something is blocked or not.

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

              I should not be able to telnet in wen a ip is blocked.
              Telnet shows connected. If i try the same with port 443 it does not give the text connected.

              It is hard to explain i guess.

              I know it looks like both are blocked correctly but it is not.
              The top 2 lines of the log image should not happen to the local ip it should show blocked to the pub ip. and not say connected in the telnet client side.

              1 Reply Last reply Reply Quote 0
              • KOMK
                KOM
                last edited by KOM

                I don't believe that's correct. You think you're connecting, but it's just timing out. I explained why the block log shows what it shows. For definitive proof, do a packet capture on the interface that your server is on, and filter it to just the server's IP address and then start and do your telnet test. Stop the capture and you wont see ANY packets have passed.

                And like I said earlier, change your block rule to a reject rule and see what happens.

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

                  It gives a timeout on any other port.
                  Wen I use port 80 it is connected.
                  And its not only me who knows this other people know this too because that is how i saw this.

                  I probably don't explain it the right way.

                  I also tested reject and many more things befor i start posting here on the forum.

                  I started up a other system again and connected via my mobile (tethering) just to take this screenshot.
                  Everything that is blurred out is the public ip of the pfsense box.

                  telnet.jpg

                  1 Reply Last reply Reply Quote 0
                  • KOMK
                    KOM
                    last edited by

                    Do the packet capture (Diagnostics - Packet Capture) and see if any traffic goes out to your server.

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

                      It looks like it is not connecting to the local webserver.
                      But it is connecting something (maybe the firewall itself) on port 80 from the outside.

                      The destination ip in this wireshark screenshot is the public ip of my pfsense box.

                      wireshark.jpg

                      1 Reply Last reply Reply Quote 0
                      • KOMK
                        KOM
                        last edited by

                        No, it's not connecting to anything. Your telnet session isn't doing anything but knocking on the door and waiting. Shortly, it will time out. The session only ever sends SYN packets and never gets a SYN ACK back, so no TCP connection is established. It doesn't matter what telnet thinks is happening or what it says. It's not really connecting. Your firewall logs shows blocks every time you try to connect and no traffic is passed out the interface.

                        1 Reply Last reply Reply Quote 1
                        • G
                          Gerard64
                          last edited by

                          Still there is a difference:

                          Wen i remove the port 80 from the http_https ports alias i get a different outcome a timeout.
                          Wen i add port 80 to the http_https ports alias i get a connection with telnet on port 80.

                          And in both these tests a different log entry.
                          The first a block on the public ip and the second on the local ip of the webserver.

                          Specially since somebody is hitting my pfsense box this way, for several days, with a lot of different ip addresses all day and night.

                          I don't know what his plan is but i am not comfortable with it.

                          1 Reply Last reply Reply Quote 0
                          • KOMK
                            KOM
                            last edited by

                            I've explained everything already and I don't know what else to tell you.

                            1 Reply Last reply Reply Quote 1
                            • G
                              Gerard64
                              last edited by

                              Oke i understand.
                              Thank you a lot for helping and thinking with me.
                              I am not yet reassured but that's probably my stubborn brain i am sorry for that.

                              Good night sir.

                              1 Reply Last reply Reply Quote 0
                              • GertjanG
                                Gertjan @Gerard64
                                last edited by Gertjan

                                @Gerard64 said in how come on a natted port 80 a blocked ip can still telnet in:

                                But i don't want to put that information out on a forum.

                                Here a my WAN rules :

                                12aeaf38-778a-4588-977c-7942758fe7b5-image.png

                                Tell, me : am I at risk now ?

                                Btw : I was one NAT rule : the one that gives "Source" hosts access to my "diskstation".

                                edit : the NAT rule :

                                3e064f53-7e17-4b4c-9d79-a38174290c27-image.png

                                No "help me" PM's please. Use the forum, the community will thank you.
                                Edit : and where are the logs ??

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