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

arad85

Hi,

First post here.

I'm in the process of upgrading my standard linksys router with one running pfSense on an N2800 Atom board. In doing so, I'm just running both connections on my internal WAN and redirecting out the linksys. I have a default install except I have unticked the "Block private networks" on the WAN port so I can do testing of port forwarding internally. When I run a port scan on the WAN port, it tells me that my one forwarded port (FTP) is open, but also tells me port 80 is open.

I can't find a default rule that opens this port. Am I missing something?

arad85

Doing a complete port scan shows the following ports open on the WAN interface: 80,3124,3127,3128,8008,8080,8081,8091,8888

I've done it with two different software packages and the results are consistent. I've also rebooted the router and the same.

Supermule

Thats not very safe….. :(

podilarius

How are you testing it? (nmap or something) Are you testing from within the LAN to the WAN address? Is it just a default install with just NIC configured or do you have packages and other config setup?

arad85

@podilarius:

How are you testing it? (nmap or something) Are you testing from within the LAN to the WAN address? Is it just a default install with just NIC configured or do you have packages and other config setup?

Testing is via NetworkActiv Port Scanner and Angry IP Scanner.

I have done a standard install (about 3 hours ago) and have 2 NICs in the machine. The LAN NIC is 192.168.1.6 statically allocated, the WAN port is 192.168.1.112 (DHCP) and is gatewayed out through my current router (192.168.1.1). Setting up a test machine so that its gateway is 192.168.1.6 (the LAN port on the new router) works nicely. I can browse the web and see the traffic on the bandwidth monitors.

The only config I have done is the NIC config, added a rule to forward FTP to my internal FTP server and installed, but not configured, snort. It is installed, the rules are updated from the internet but there is no configuration that I've applied to it so it isn't running (services->status shows it as stopped).

All I am then doing is from another machine on the network I'm just running a portscan on the WAN port and both pieces of software report that the ports are open.

If you try and connect to the ports (port 80) via a web browser, it doesn't reply with anything. Putting a rule in the WAN firewall to silently drop anything appearing as TCP on port 80 and log it produces no log entries as far as I can tell.

I also have this set up in a virtual machine and running the tests on the VM'd router shows the ports "open" as well….

arad85

This is what nmap 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 19:13 ope
Nmap scan report for 192.168.1.112
Host is up (0.0034s 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)

and logging into the console and looking at the filter logs I get nothing

If I try another TCP connection method (for example -sW) I get the following reported by nmap:

$ nmap -sW -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 19:22 ope
Nmap scan report for 192.168.1.112
Host is up (0.00s 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)

and the following in the log file:

00:03:39.367808 rule 32/0(match): block in on em0: 192.168.1.24.55747 > 192.168.1.112.80: [|tcp]
00:00:01.105177 rule 32/0(match): block in on em0: 192.168.1.24.55748 > 192.168.1.112.80: [|tcp]

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.

arad85

@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.

cmb

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.

arad85

??? 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>

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.

arad85

@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

arad85

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.

arad85

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.

podilarius

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.

arad85

@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.

cmb

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.

arad85

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.

arad85

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….

podilarius

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.