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

    2.0.1 seems to show a number of ports open on WAN by default

    Firewalling
    4
    21
    15.7k
    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.
    • P
      podilarius
      last edited by

      You can be in the same physical network, but be on separate subnets. That would be a better test than having them in the same subnet.

      WAN - in the 192.168.1/24 network with a gateway of .1
      LAN - in the 192.168.11/24 network.
      Then you can check your ports without the possibility of cross talk.

      If you are going to test, at least simulate actual network design more closely.

      1 Reply Last reply Reply Quote 0
      • A
        arad85
        last edited by

        @podilarius:

        You can be in the same physical network, but be on separate subnets. That would be a better test than having them in the same subnet.

        WAN - in the 192.168.1/24 network with a gateway of .1
        LAN - in the 192.168.11/24 network.
        Then you can check your ports without the possibility of cross talk.

        If you are going to test, at least simulate actual network design more closely.

        OK…

        Now have the test PC on 192.168.11.23, the LAN interface on 192.168.11.6 and the WAN interface on 192.168.1.112 with a gateway of 192.168.1.1.

        Testing from the 192.168.11.23 machine gives:

        $ nmap -sT -p T:80,3124,3128,3127,8008,8080,8888,8081 192.168.1.112

        Starting Nmap 5.51 ( http://nmap.org ) at 2012-05-09 23:29 ope
        Nmap scan report for (192.168.1.112)
        Host is up (0.0041s latency).
        PORT     STATE     SERVICE
        80/tcp   open      http
        3124/tcp filtered  unknown
        3127/tcp filtered  unknown
        3128/tcp filtered  squid-http
        8008/tcp filtered  http
        8080/tcp filtered  http-proxy
        8081/tcp filtered  blackice-icecap
        8888/tcp filtered  sun-answerbook

        Nmap done: 1 IP address (1 host up) scanned in 1.25 seconds

        Testing from a machine on the .1.xx to the .1.112 address subnet gives:

        $ nmap -sT -p T:80,3124,3128,3127,8008,8080,8888,8081 192.168.1.112

        Starting Nmap 5.51 ( http://nmap.org ) at 2012-05-09 23:33 ope
        Nmap scan report for 192.168.1.112
        Host is up (0.0029s latency).
        PORT     STATE SERVICE
        80/tcp   open  http
        3124/tcp open  unknown
        3127/tcp open  unknown
        3128/tcp open  squid-http
        8008/tcp open  http
        8080/tcp open  http-proxy
        8081/tcp open  blackice-icecap
        8888/tcp open  sun-answerbook
        MAC Address: 00:22:4D:7C:31:06 (Mitac International)

        Nmap done: 1 IP address (1 host up) scanned in 11.25 seconds

        If I remove the cable from the WAN port and retest on the .1.xx machine I get:

        $ nmap -sT -p T:80,3124,3128,3127,8008,8080,8888,8081 192.168.1.112

        Starting Nmap 5.51 ( http://nmap.org ) at 2012-05-09 23:34 ope
        Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
        Nmap done: 1 IP address (0 hosts up) scanned in 0.62 seconds

        1 Reply Last reply Reply Quote 0
        • A
          arad85
          last edited by

          One further bit of information. If I test 192.168.1.1 from the .1.xx subnet I get:

          $ nmap -sT -p T:80,3124,3128,3127,8008,8080,8888,8081 192.168.1.1

          Starting Nmap 5.51 ( http://nmap.org ) at 2012-05-09 23:39 ope
          Nmap scan report for wrt610n.home (192.168.1.1)
          Host is up (0.0048s latency).
          PORT     STATE SERVICE
          80/tcp   open  http
          3124/tcp open  unknown
          3127/tcp open  unknown
          3128/tcp open  squid-http
          8008/tcp open  http
          8080/tcp open  http-proxy
          8081/tcp open  blackice-icecap
          8888/tcp open  sun-answerbook
          MAC Address: 00:22:6B:7A:76:74 (Cisco-Linksys)

          Nmap done: 1 IP address (1 host up) scanned in 11.25 seconds

          Showing all the  ports that are opened on the pfsense router are also open on the actual gateway internal interface.

          1 Reply Last reply Reply Quote 0
          • A
            arad85
            last edited by

            OK, now I'm confused.

            I dug out a different router and plugged the WAN port and the test PC into this router. The DHCP address is different (now 1.33) but the network is very simple: one PC at 192.168.1.23, one WAN port at 192.168.1.33 and the router at 192.168.1.1. The router was not connected out to anything

            Doing a portscan of the same ports on the new WAN address shows:

            $ nmap -sT -p T:80,3124,3127,3128,8008,8080,8081,8888 192.168.1.33

            Starting Nmap 5.51 ( http://nmap.org ) at 2012-05-10 08:45 GMT Daylight Time
            Nmap scan report for 192.168.1.33
            Host is up (0.010s latency).
            PORT    STATE    SERVICE
            80/tcp  filtered http
            3124/tcp filtered unknown
            3127/tcp filtered unknown
            3128/tcp filtered squid-http
            8008/tcp filtered http
            8080/tcp filtered http-proxy
            8081/tcp filtered blackice-icecap
            8888/tcp filtered sun-answerbook
            MAC Address: 00:22:4D:7C:31:06 (Mitac International)

            Nmap done: 1 IP address (1 host up) scanned in 14.73 seconds

            which is more in line with what I would expect.

            So the apparent behaviour of the WAN port seems dependent on which network it is attached to…. That's just weird.

            1 Reply Last reply Reply Quote 0
            • P
              podilarius
              last edited by

              I just ran the same command against a fresh install with only the NICs configured. No packages or custom NAT is being done.

               # nmap -sT -p T:80,3124,3127,3128,8008,8080,8081,8888 10.13.13.233

Starting Nmap 5.21 ( http://nmap.org ) at 2012-05-10 10:09 EDT
Nmap scan report for 10.13.13.233
Host is up (0.00042s latency).
PORT     STATE    SERVICE
80/tcp   filtered http
3124/tcp filtered unknown
3127/tcp filtered unknown
3128/tcp filtered squid-http
8008/tcp filtered http
8080/tcp filtered http-proxy
8081/tcp filtered blackice-icecap
8888/tcp filtered sun-answerbook

              I am not sure what you are doing in your setup, but something is not configured correctly.

              1 Reply Last reply Reply Quote 0
              • A
                arad85
                last edited by

                @podilarius:

                I am not sure what you are doing in your setup, but something is not configured correctly.

                Thanks for trying this.

                I have not changed the configuration between plugging the pfsense box between the two routers and I get two different answers depending on which router it is connected to! This I don't understand at all.

                I also don't understand why nmap sees the ports as there - surely the job of pfsense should be just to drop everything silently unless configured otherwise.

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

                  You're scanning from the LAN from the sounds of it, which allows everything by default. If you're scanning from the WAN side, nothing will answer. And make sure you put them on separate subnets, there can be conflicts on which rules actually get applied depending on the status of the ARP table when you have a broken config with two NICs on the same subnet.

                  Also get a packet capture of what's really happening, from Diag>Packet Capture preferably, and post the pcap here or at least the full verbosity text output. Someone comes along here once every few months with the same "OMG I have ports open but no rules to allow!!1!1" and it's never actually the case, though why it's showing that varies greatly from one screw up to another.

                  1 Reply Last reply Reply Quote 0
                  • A
                    arad85
                    last edited by

                    OK, it's not a screwup - at least with pfsense setup - honest ;) and I'm partially there as to understanding what's going on.

                    At present, the pfsense box has both physical ethernet connectors on the same physical network (same switch). They both (in fact all my machines) have 192.168.1.0/24 addresses - I don't believe that has anything to do with the problem (or if it has, then something is seriously screwy in how pf works). I am nmapping it from another machine on the same network (what I termed the LAN, but could be confused for the box itself). All I am doing is port probing the WAN IP address with packets from another physically separate machine (at address 192.168.1.24). My WAN address is 192.168.1.112 and my LAN address is 192.168.1.6.

                    The first question of why it sees the machine as there (and hence why in other port scans they are seen as filtered) is quite simple. As part of the preamble when nmap works, it does this (this is a capture from the Packet Capture screen):

                    13:28:10.784155 bc:ae:c5:76:ae:5f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.112 (ff:ff:ff:ff:ff:ff) tell 192.168.1.24, length 46
                    13:28:10.784170 00:22:4d:7c:31:06 > bc:ae:c5:76:ae:5f, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.112 is-at 00:22:4d:7c:31:06, length 28

                    I guess the pfSense box has to acknowledge this as it could be coming from the ISP machine.

                    nmap can be run with a variety of different TCP connection methods:

                    SCAN TECHNIQUES:
                     -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans
                     -sU: UDP Scan
                     -sN/sF/sX: TCP Null, FIN, and Xmas scans

                    Running any of S/T/A/W/M scans results in the above MAC address handshake occurring.

                    Running the S/A/W nmap with

                    $ nmap -sA -p T:80,3124,3128,3127,8008,8080,8888,8081 192.168.1.112

                    gives:

                    Starting Nmap 5.51 ( http://nmap.org ) at 2012-05-11 14:03 ope
                    Nmap scan report for 192.168.1.112
                    Host is up (0.0010s latency).
                    PORT     STATE    SERVICE
                    80/tcp   filtered http
                    3124/tcp filtered unknown
                    3127/tcp filtered unknown
                    3128/tcp filtered squid-http
                    8008/tcp filtered http
                    8080/tcp filtered http-proxy
                    8081/tcp filtered blackice-icecap
                    8888/tcp filtered sun-answerbook
                    MAC Address: 00:22:4D:7C:31:06 (Mitac International)

                    Nmap done: 1 IP address (1 host up) scanned in 12.44 seconds

                    and the following in the packet capture (or similar):

                    192.168.1.24.43152 > 192.168.1.112.8080: Flags [ S], cksum 0x25d6 (correct), seq 3742122826, win 1024, options [mss 1460], length 0
                    13:28:01.286855 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 45, id 21944, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43152 > 192.168.1.112.80: Flags [ S], cksum 0x4116 (correct), seq 3742122826, win 2048, options [mss 1460], length 0
                    13:28:01.287068 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 54, id 8691, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43152 > 192.168.1.112.8888: Flags [ S], cksum 0x1aae (correct), seq 3742122826, win 3072, options [mss 1460], length 0
                    13:28:01.287204 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 44, id 42268, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43152 > 192.168.1.112.3127: Flags [ S], cksum 0x392f (correct), seq 3742122826, win 1024, options [mss 1460], length 0
                    13:28:01.287382 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 54, id 28704, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43152 > 192.168.1.112.3124: Flags [ S], cksum 0x3132 (correct), seq 3742122826, win 3072, options [mss 1460], length 0
                    13:28:01.287558 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 44, id 57212, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43152 > 192.168.1.112.8008: Flags [ S], cksum 0x261e (correct), seq 3742122826, win 1024, options [mss 1460], length 0
                    13:28:01.287736 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 38, id 28605, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43152 > 192.168.1.112.3128: Flags [ S], cksum 0x312e (correct), seq 3742122826, win 3072, options [mss 1460], length 0
                    13:28:01.287913 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 53, id 16770, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43152 > 192.168.1.112.8081: Flags [ S], cksum 0x21d5 (correct), seq 3742122826, win 2048, options [mss 1460], length 0
                    13:28:02.390583 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 58, id 11792, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43153 > 192.168.1.112.8081: Flags [ S], cksum 0x1dd2 (correct), seq 3742188363, win 3072, options [mss 1460], length 0
                    13:28:02.390706 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 55, id 39090, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43153 > 192.168.1.112.3128: Flags [ S], cksum 0x2d2b (correct), seq 3742188363, win 4096, options [mss 1460], length 0
                    13:28:02.390864 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 54, id 46187, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43153 > 192.168.1.112.8008: Flags [ S], cksum 0x1e1b (correct), seq 3742188363, win 3072, options [mss 1460], length 0
                    13:28:02.391050 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 46, id 51374, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43153 > 192.168.1.112.3124: Flags [ S], cksum 0x312f (correct), seq 3742188363, win 3072, options [mss 1460], length 0
                    13:28:02.391237 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 52, id 50348, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43153 > 192.168.1.112.3127: Flags [ S], cksum 0x392c (correct), seq 3742188363, win 1024, options [mss 1460], length 0
                    13:28:02.391415 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 57, id 35607, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43153 > 192.168.1.112.8888: Flags [ S], cksum 0x1eab (correct), seq 3742188363, win 2048, options [mss 1460], length 0
                    13:28:02.391607 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 45, id 44370, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43153 > 192.168.1.112.80: Flags [ S], cksum 0x4113 (correct), seq 3742188363, win 2048, options [mss 1460], length 0
                    13:28:02.391819 bc:ae:c5:76:ae:5f > 00:22:4d:7c:31:06, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 37, id 52753, offset 0, flags [none], proto TCP (6), length 44)
                       192.168.1.24.43153 > 192.168.1.112.8080: Flags [ S], cksum 0x21d3 (correct), seq 3742188363, win 2048, options [mss 1460], length 0

                    So, it is seeing the probes but not responding to them as it should do.

                    The really interesting one is what is happening in the logs if I run:

                    $ nmap -sT -p T:80,3124,3128,3127,8008,8080,8888,8081 192.168.1.112

                    Starting Nmap 5.51 ( http://nmap.org ) at 2012-05-11 14:44 ope
                    Nmap scan report for 192.168.1.112
                    Host is up (0.0042s latency).
                    PORT    STATE SERVICE
                    80/tcp  open  http
                    3124/tcp open  unknown
                    3127/tcp open  unknown
                    3128/tcp open  squid-http
                    8008/tcp open  http
                    8080/tcp open  http-proxy
                    8081/tcp open  blackice-icecap
                    8888/tcp open  sun-answerbook
                    MAC Address: 00:22:4D:7C:31:06 (Mitac International)

                    Nmap done: 1 IP address (1 host up) scanned in 11.27 seconds

                    This is the (complete) log for the interface in that case:

                    14:17:50.396722 bc:ae:c5:76:ae:5f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.112 (ff:ff:ff:ff:ff:ff) tell 192.168.1.24, length 46
                    14:17:50.396739 00:22:4d:7c:31:06 > bc:ae:c5:76:ae:5f, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.112 is-at 00:22:4d:7c:31:06, length 28

                    Something else is getting the packets! I've checked it isn't the LAN interface on the router.

                    Off to look at that now.

                    Many thanks for your help so far - I'll update the thread when I figure out what is picking up the packets just to close it off.

                    1 Reply Last reply Reply Quote 0
                    • A
                      arad85
                      last edited by

                      Well… the story gets stranger and stranger... If you run nmap on a Win7 machine you get:

                      $ nmap -sT -p T:80,3124,3128,3127,8008,8080,8888,8081 192.168.1.112

                      Starting Nmap 5.51 ( http://nmap.org ) at 2012-05-11 20:32 GMT Daylight Time
                      Nmap scan report for 192.168.1.112
                      Host is up (0.019s latency).
                      PORT    STATE SERVICE
                      80/tcp  open  http
                      3124/tcp open  unknown
                      3127/tcp open  unknown
                      3128/tcp open  squid-http
                      8008/tcp open  http
                      8080/tcp open  http-proxy
                      8081/tcp open  blackice-icecap
                      8888/tcp open  sun-answerbook
                      MAC Address: 00:22:4D:7C:31:06 (Mitac International)

                      Nmap done: 1 IP address (1 host up) scanned in 18.23 seconds

                      I've tried it on a few Win7 machines here and it is consistent. From an XP machine or one running Linux or FreeBSD, I get the ports as filtered - not open. The result is OS dependent.

                      I also have a managed router here and have port mirrored the Win7 port into Wireshark. Using nmap -sT option the packets don't even come out of the Ethernet port on the Win 7 machine according to Wireshark. I know I have Wireshark configured correctly as when I use any of the other TCP protocols, they appear in the Wireshark (and pfSense) logs.

                      The problem is somewhere in Win7 or nmap (more likely IMHO). Everything else is consistent and - most importantly - isn't a problem with pfSense….

                      1 Reply Last reply Reply Quote 0
                      • P
                        podilarius
                        last edited by

                        Yet Again … the problem is outside pfSense.  ;)

                        You might have a Virus program monitoring those ports or something. Try disabling that and the Windows firewall and see if you get a different outcome.

                        1 Reply Last reply Reply Quote 0
                        • A
                          arad85
                          last edited by

                          @podilarius:

                          You might have a Virus program monitoring those ports or something. Try disabling that and the Windows firewall and see if you get a different outcome.

                          Yup. Avast was picking up the requests and dropping them. That was such an obvious candidate too  >:(::) (where's the head-bashing-against-the-wall smiley when you need it) The XP machine doesn't run any a/v (it's just for testing like I've been doing!) so was reporting correctly.

                          Still, it was an interesting couple of days debugging (even to the point of setting up a wireshark machine and port mirroring to see what was happening on the network for the first time…) and lesson learned.

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