"Default deny rule" blocks incoming connections on OPT
-
So, here is the whole thing. I'm trying to NAT the incoming connections on OPT:22 (WAN) to 192.168.1.101:22 on LAN side so i created the NAT rule this way:
Interface: WAN2 (OPT1) Protocol: TCP Destination.Type: Single Host or Alias Destination.Address: 10.10.10.100 (The IP address on WAN2) Destination port [from]: SSH Destination port [to]: SSH Redirect Target IP: 192.168.1.101 Redirect Target port: SSH NAT reflection: Use system default Filter rule association: Rule NAT
Anyway, when i try to connect from a host on the WAN2 side i get this in the firewall log:
Act Time If Source Destination Proto
block Jun 6 21:41:46 WAN2 10.10.10.149:55208 10.10.10.100:22 TCP:S
block Jun 6 21:41:47 WAN2 10.10.10.149:55208 10.10.10.100:22 TCP:S
block Jun 6 21:41:48 WAN2 10.10.10.149:55208 10.10.10.100:22 TCP:S
block Jun 6 21:41:50 WAN2 10.10.10.149:55208 10.10.10.100:22 TCP:S
block Jun 6 21:41:51 WAN2 10.10.10.149:55208 10.10.10.100:22 TCP:S
block Jun 6 21:41:52 WAN2 10.10.10.149:55208 10.10.10.100:22 TCP:S
block Jun 6 21:41:54 WAN2 10.10.10.149:55208 10.10.10.100:22 TCP:SIn all of them the debug information is the same:
The rule that triggered this action is: @1 scrub in on le2 all fragment reassemble @1 block drop in log all label "Default deny rule"
So i decided to use a little brute force and create this floating rule:
Action: Pass Quick: TRUE Interface: LAN,WAN2 Direction: Any Protocol: Any Source: Any Destination: Any
The problem keeps going, i can't connect via SSH to 192.168.1.101 nor ping 10.10.10.100, or even access http (pfSense webConfiguration) on 10.10.10.100. The blocking reason is allways the same
The rule that triggered this action is: @1 scrub in on le2 all fragment reassemble @1 block drop in log all label "Default deny rule"
I'm using pfSense 2.0.1 under VMWare and i can perfectly browse internet from 192.168.1.101
What am i doing wrong?
-
Something is wrong with your port forward, because you should be seeing 192.168.1.101 as the destination in the firewall log if it is logged, not 10.10.10.100. Typically this means your rule does not match the connections. Did you specify a source port? If so, clear it.