Hello Matthew
Let’s isolate the configurations that directly affect the specific transaction that you described in your post, that is the communication between the 192.168.10.179 device in the DMZ, and the 192.168.1.181 host on the INSIDE network:
Here’s your access list that matches the traffic from the DMZ network to the specific host on the INSIDE network:
ip access-list extended DMZ-TO-INSIDE
10 permit tcp 192.168.10.0 0.0.0.255 host 192.168.2.181 eq 22
Here’s the class map that references that ACL to match traffic:
class-map type inspect match-all DMZ-TO-INSIDE-CLASS
match access-group name DMZ-TO-INSIDE
Here’s the policy map that references the class map:
policy-map type inspect DMZ-TO-INSIDE-POLICY
class type inspect DMZ-TO-INSIDE-CLASS
pass
class class-default
drop log
Finally, here’s the zone pair that references that policy map:
zone-pair security DMZ-TO-IN source DMZ destination INSIDE
service-policy type inspect DMZ-TO-INSIDE-POLICY
Based on the policy map, anything that matches the ACL will be passed, but everything else should indeed be dropped. Only an SSH session (TCP port 22) should be allowed. You have the drop keyword in the class-default of the policy map, so you should be OK.
So at first glance, I don’t see the reason for the behavior. I suggest you take a look at this lesson first:
Then you can use some of the verification and debugging parameters to examine your traffic to see where it is going. The show policy-map type inspect zone-pair command is useful. Also, you can use some of the following debugs:
debug policy-firewall eventsdebug ip packet detail access-list <acl number>debug ip inspect detail
I hope this will help you to get a start on things. Let us know how you get along and how we can be of further help.
I hope this has been helpful!
Laz