I have been attempting to get a 582n to log these packets for the past few days. I have not exactly succeeded but have discovered something else which I think indicates that the 582n's firewall isn't particularly "stealthy".
The first step of the configuration is to create an expression which represents all 4 of those IP addresses.
:expr add name=pncommunitylog type=ip addr=84.93.230.178
:expr add name=pncommunitylog type=ip addr=84.93.230.186
:expr add name=pncommunitylog type=ip addr=84.93.235.210
:expr add name=pncommunitylog type=ip addr=84.93.235.226
I added these firewall rules which I expected to match and log incoming packets from those 4 IPs, but these rules never got any hits, nothing was ever logged.
:firewall rule add chain=sink index=1 srcip=pncommunitylog log=enabled state=enabled action=accept
:firewall rule add chain=forward_custom index=1 srcip=pncommunitylog log=enabled state=enabled action=accept
:firewall rule add chain=source index=1 srcip=pncommunitylog log=enabled state=enabled action=accept
Just now I tried adding rules which log
outbound packets going to those 4 IP addresses:
:firewall rule add chain=sink index=1 dstip=pncommunitylog log=enabled state=enabled action=accept
:firewall rule add chain=forward_custom index=1 dstip=pncommunitylog log=enabled state=enabled action=accept
:firewall rule add chain=source index=1 dstip=pncommunitylog log=enabled state=enabled action=accept
By default all outbound traffic is allowed, so the action=accept shouldn't make any difference.
I was surprised to see outbound ICMP packets being logged to these 4 IP addresses:
| Quote |
| <84> Nov 15 12:35:20 FIREWALL rule (1 of 6) : Protocol: ICMP Src ip: 87.115.my.ip Dst ip: 84.93.235.210 Type: Destination Unreachable Code: Port Unreacheable Chain: source Rule Id: 1 Action: accept |
I'm pretty sure my computer isn't replying to these spurious packets from 84.93.235.210, since these packets never reach my computer. That implies it must be the 582n that is sending ICMP packets to the spurious packets from 84.93.235.210. I would have expected it to silently drop the packets, not respond to them.
Furthermore, I also tried telnetting to 84.93.235.210:44340:
| Quote |
<84> Nov 15 12:44:59 FIREWALL rule (1 of 1) : Protocol: TCP Src ip: 192.168.1.101 Src port: 50915 Dst ip: 84.93.230.178 Dst port: 44340 Chain: forward_custom Rule Id: 1 Action: accept
<81> Nov 15 12:46:09 FIREWALL icmp check (1 of 1): Protocol: ICMP Src ip: 84.93.232.16 Dst ip: 87.115.my.ip Type: Destination Unreachable Code: Communication Administratively Prohibited |
The first log entry is the outgoing packet from my computer being logged, as expected. However, the second log entry seems to be the response being blocked by the 582n firewall, which should have been forwarded to my computer. As I said in an earlier post in this thread, you can't connect to tcp port 44340 on any of those 4 IP addresses, you get an ICMP packet containing the error message from an intermediate router.
So, in summary:
1. I did not succeed in getting the 582n to log these spurious ACK packets it receives.
2. The 582n appears to be sending out ICMP response packets to these spurious packets, indicating it's firewall isn't "stealthy" (doesn't silently drop them).
3. The 582n firewall incorrectly blocked an ICMP response that should have reached my computer, although that could have been because it hit the 582n 70 seconds after the outgoing packet, and 70 seconds may be longer than some timeout value after which the 582n forgets about the outgoing connection attempt.
