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

    Scheduled Pinned Locked Moved Firewalling
    21 Posts 4 Posters 15.9k 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.
    • A
      arad85
      last edited by

      @podilarius:

      Unless you are using a small class C, your WAN and LAN are in the same network. This is not usually a good idea and could cause unwanted effects. I would not consider this a typical setup or a very safe one for that matter. I am actually surprised that it even passes packets for you. Though I suppose it would in 2.0.1.

      It's there for testing purposes but it should do exactly what it is told to do  - take packets from the "LAN" interface and route them to the gateway the "WAN" interface sees. The reason it is like this is because I'm just getting it set up without breaking the internet connection for others. The question is why are the ports open? I want to remain completely stealthed on the internet and as internally I can "see" the interface, I assume when it's moved externally, people will be able to see me too.

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

        Nothing is open on WAN by default. You have to have more than just rules there for all that to be showing up. Worst case scenario on an out of the box install, completely disable the firewall and you'll have 53 (DNS forwarder), 80 (HTTP to HTTPS redirect) and 443 (HTTPS management) open. That's it. You either have a number of port forwards with firewall rules allowing traffic through to some other host (though with LAN and WAN on the same subnet that'd be hit and miss at best), or are scanning something else entirely.

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

          ??? It is out of the box…

          Here are my rules

          [root]$ pfctl -s rules
          scrub in on em0 all fragment reassemble
          scrub in on em1 all fragment reassemble
          anchor "relayd/" all
          block drop in log all label "Default deny rule"
          block drop out log all label "Default deny rule"
          block drop in quick inet6 all
          block drop out quick inet6 all
          block drop quick proto tcp from any port = 0 to any
          block drop quick proto tcp from any to any port = 0
          block drop quick proto udp from any port = 0 to any
          block drop quick proto udp from any to any port = 0
          block drop quick from <snort2c>to any label "Block snort2c hosts"
          block drop quick from any to <snort2c>label "Block snort2c hosts"
          block drop in log quick proto tcp from <sshlockout>to any port = ssh label "sshlockout"
          block drop in log quick proto tcp from <webconfiguratorlockout>to any port = https label "webConfiguratorlockout"
          block drop in quick from <virusprot>to any label "virusprot overload table"
          block drop in log quick on em0 from <bogons>to any label "block bogon networks from WAN"
          block drop in on ! em0 inet from 192.168.1.0/24 to any
          block drop in inet from 192.168.1.112 to any
          block drop in on em0 inet6 from fe80::222:4dff:fe7c:3106 to any
          pass in on em0 proto udp from any port = bootps to any port = bootpc keep state label "allow dhcp client out WAN"
          pass out on em0 proto udp from any port = bootpc to any port = bootps keep state label "allow dhcp client out WAN"
          block drop in on ! em1 inet from 192.168.1.0/24 to any
          block drop in inet from 192.168.1.6 to any
          block drop in on em1 inet6 from fe80::6a05:caff:fe03:a8a5 to any
          pass in on lo0 all flags S/SA keep state label "pass loopback"
          pass out on lo0 all flags S/SA keep state label "pass loopback"
          pass out all flags S/SA keep state allow-opts label "let out anything from firewall host itself"
          pass out route-to (em0 192.168.1.1) inet from 192.168.1.112 to ! 192.168.1.0/24 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
          pass in quick on em1 proto tcp from any to (em1) port = http flags S/SA keep state label "anti-lockout rule"
          pass in quick on em1 proto tcp from any to (em1) port = https flags S/SA keep state label "anti-lockout rule"
          pass in quick on em1 proto tcp from any to (em1) port = ssh flags S/SA keep state label "anti-lockout rule"
          anchor "userrules/          " all
          pass in quick on em0 reply-to (em0 192.168.1.1) inet proto tcp from any to <mainserver>port = ftp flags S/SA keep state label "USER_RULE: NAT FTP port to mainserver"
          block drop in log quick on em0 reply-to (em0 192.168.1.1) inet proto tcp from any to any port = http label "USER_RULE: HTTP port block"
          block drop in log quick on em0 reply-to (em0 192.168.1.1) inet proto udp from any to any port = http label "USER_RULE: HTTP port block"
          pass in quick on em1 inet from 192.168.1.0/24 to any flags S/SA keep state label "USER_RULE: Default allow LAN to any rule"
          anchor "tftp-proxy/*" all
          [root]$

          Is there anything else I can run to figure out what the routing tables are doing?</mainserver></bogons></virusprot></webconfiguratorlockout></sshlockout></snort2c></snort2c>

          1 Reply Last reply Reply Quote 0
          • 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.