"Default deny rule" blocks incoming connections on OPT

eherrera

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:S

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

Efonnes

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.