NMAP says all TCP ports are open….but they aren't really..

  • I'm new to pfSense.  I'm seeing some behaviour I'm not used to with firewalls.  My firewall rules are set up to allow traffic on some ports 80, 22 (though 22 this is port forwarded from another port on WAN via NAT), PPTP etc.  Last rule is a reject all rule.

    What I would expect to see is NMAP showing just the handful of ports I've explicitly opened as open while everything else as closed.  I'm not seeing this.  I am seeing lots of opened ports.  ShieldsUp also show lots of open ports.

    Now the strangest part.  If I run a nmap -sV to probe the port for the type of service there I see "tcpwrapped" as the service for all those opened ports that shouldn't be opened.  The ones I explicitly opened myself show the correct service.  Also, ShieldsUp when instructed to probe a single port will show it as closed (which I would expect), even though it showed it as opened when it scans a large range.

    My question is…what's going on?? Seems like pfSense is replying on these ports (though I don't want it to, other than to say sorry we're closed).

    2.1-RELEASE (i386)
    built on Wed Sep 11 18:16:22 EDT 2013
    FreeBSD 8.3-RELEASE-p11

    I've attached the various NMAP and ShieldsUP outputs with my FW rules.

    Thanks so much.  Love pfSense! Just need to learn more :)


  • LAYER 8 Global Moderator

    Well you have a REJECT rule there for * – what do think would happen?  Remove that and the default block will just drop all traffic vs replying with RST.

  • @johnpoz:

    Well you have a REJECT rule there for * – what do think would happen?  Remove that and the default block will just drop all traffic vs replying with RST.

    Thanks for the reply.

    I would think pfSense would reply with a reject packet which NMAP and SheildsUP would translate into "closed" not "open".

    Changing the rule to "block" instead of "reject".  ShieldsUP now shows many more ports as "opened", NMAP still shows lots of opened ports.  When I tell ShieldsUp to probe an individual port instead of a range of ports it will come back to say "stealth" as one would expect (same as my first post).

    I'd like to know why broad port scans shows ports as open when it really shouldn't be.  pfSense seems to be replying on these closed or blocked ports in some way that it shouldn't be.

  • LAYER 8 Global Moderator

    So just did scan of my pfsense box, and only port it shows open is the one I have open, ie my openvpn listening on 443.

    Below that are my wan rules - so you see 443 is open, the other forwards like 5001 and dvr ones are above the range scanned but those would also show open.  Others are UDP

    You have something in front of your pfsense?  Do have any rules in your floating tab?  I find very hard to believe that pfsense is listening on those ports, so would have to be something forwarding to something that is?  Or you have something infront of it.  Let me create a specific reject rule for a port and see what shields up says about that.

    edit: ok so next 2 images are my reject rule and what shields yup closed vs stealthed.

    edit2: so on your pfsense box see if pfsense is listening on those ports that say are open?  sockstat -4 -l -P TCP

    See my last attached example from my pfsense

  • There is a modem/router from my ISP in front.  But pfSense is in the DMZ.

    What version are you on?  It just a very odd behaviour.  I'll have a look at your stuff and check the netstat and sockstat as well.


  • LAYER 8 Global Moderator

    "There is a modem/router from my ISP in front.  But pfSense is in the DMZ."

    So the device in front of you is doing nat then?  Your pfsense wan does not have a public IP on it?

    I am the current version of pfsense
    2.1-RELEASE (i386)
    built on Wed Sep 11 18:16:50 EDT 2013
    FreeBSD 8.3-RELEASE-p11

    Here is the thing, the odds of pfsense listening on those ports is pretty close to nil..  Do a simple sockstat and see for yourself.  So if pfsense is not listening on the ports.. What would answer to show it open?  You would have to some forwarded in a nat on pfsense, and then a firewall rule sending to that IP.  You clearly in your rules do not have that from what I can see – so what would answer?

    Do another real simple test to see if its even hitting your pfsense on those ports and sending back an ack or anything.  Simple sniff!  See first pic where you can easy see the port scan as the ports change by 1.  So you can see the scan, and clearly no answers back to that IP in the sniff.

    What you should see since your default rule should block all unsolicited traffic like that is (if your logging the default rule) is the scan come in and be blocked.  So do you see them on the sniff with an answer?  Do you not see them in the block?

    The other traffic in the sniff is my vpn connection in from work.  Notice its on 443.

    So if pfsense was actually answering.. or something inside pfsense was answering you would see it in the sniff.  See the last picture attached.  Remember those reject rules that showed closed, pfsense sends a RST..  You can see the answers in my sniff.  So if pfsense was open, or something behind pfsense was open you would see the response in your sniff..  So do a simple sniff while your scanning - do you see the answers coming back from pfsense??  If so then we clearly have something to look into why that is happening.  But its more likely something in front of pfsense is causing the problem

  • Yes there's a double NAT on my network but since pfSense is in the DMZ all traffic goes right down to it.  I'm sure there's nothing to worry about any services being open on those ports.

    But there does seem to be some odd behaviour.

  • LAYER 8 Global Moderator

    See my edit with the sniff showing the answer from pfsense in the scan with my rejects.. If the ports are being sent to pfsense and pfsense or something behind it is answering and showing it open.  Then you should see that in simple sniff.

    My point of the double nat is THAT is the device that holds your public IP.. It is most likely that device causing you what your seeing in the scans.