Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
New Member

ASA 8.4 - Static NAT configuration ignoring outside ACL

Hi,

I have an inside host configured with it's own external IP (not the outside IP), that seems to be ignoring the ACL configured for the outside interface. All traffic is passing.

My config looks like this:

interface Vlan1

nameif inside

security-level 100

ip address 172.16.33.253 255.255.255.0

interface Vlan2

nameif outside

security-level 0

ip address XXX.XXX.XXX.1 255.255.255.248

object network host-dunstable-blackberry

host 172.16.33.213

nat (inside,outside) static XXX.XXX.XXX.2

access-list acl-outside-in extended deny tcp any object host-dunstable-blackberry eq ssh

access-group acl-outside-in in interface outside

XXX.XXX.XXX.2 falls within XXX.XXX.XXX.1 255.255.255.248

Even so, I'm still able to SSH from an unrelated IP, to XXX.XXX.XXX.2, and access my server.

Does anybody have any ideas? Is this by design? If so, how can I restrict access to this machine?

Any help would be greatly appreciated,

John

Everyone's tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions
Super Bronze

ASA 8.4 - Static NAT configuration ignoring outside ACL

Hi,

Can you provide us with the output of the following command (Naturally fill in the actual public IP)

packet-tracer input outside tcp 1.1.1.1 12345 x.x.x.2 22

This should probably tell us what is allowing the traffic.

- Jouni

2 REPLIES
Super Bronze

ASA 8.4 - Static NAT configuration ignoring outside ACL

Hi,

Can you provide us with the output of the following command (Naturally fill in the actual public IP)

packet-tracer input outside tcp 1.1.1.1 12345 x.x.x.2 22

This should probably tell us what is allowing the traffic.

- Jouni

New Member

ASA 8.4 - Static NAT configuration ignoring outside ACL

Hi Jouni,

Thanks for taking the time to look at this. Performing the packet-trace shows that the traffic being blocked by the implicit deny on the outside interface.

Attempting to connect again showed that this was indeed the case.

I have no idea what was happening before, but everything seems to be working fine. It must be user error, but I'm certain I tested correctly initially... very confusing!

Thanks again,

John

626
Views
0
Helpful
2
Replies
CreatePlease to create content